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The Telescience Testbed Pilot Program is an innovative activity involving fifteen 
universities in a user-oriented rapid-prototyping testbed to develop the requirements and 
technologies appropriate to the information system of the Space Station era. 

This is the fourth quarterly report, covering the period March 1 , 1988 through August 31 , 1988. 


Work reported herein was supported by Contract NASW-4234 from the National Aeronautics and Space 
Administration (NASA) to the Universities Space Research Association (USRA). 
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1.0 INTRODUCTION 


The Telescience Testbed Pilot Program (TTPP) is intended to develop initial 
recommendations for requirements and design approaches for the information systems of the 
Space Station era. Multiple scientific experiments are being carried out, each exploiting 
advanced technologies and technical approaches and each emulating some aspect of Space 
Station era science. The aggregate results of the program will serve to guide the 
development of future NASA information systems. 


2.0 PROGRAMMATIC SUMMARY 


The second meeting of the TTPP participants and interested parties was held 7-9 March 
1988 at the University of Colorado, Boulder. This was a highly successful meeting with 
presentations made by all of the university subcontractors, as well as some related 
presentations by other organizations. Working sessions were held by each of the discipline 
areas, in order to coordinate their activities. Demonstrations of a number of activities were 
given, particularly those involved in workstation and networking applications. Copies of the 
vugraphs may be obtained by contacting Lorraine Fisher at RIACS (llf@riacs.edu). 

A contract extension for the RIACS/USRA portion of the TTPP was approved to 3 1 
December 1988. All of the university subcontracts were then extended to 31 October 1988. 
This will allow each of the universities to complete the initial phases of their experiments 
and for the results to be integrated into an overall final report. 

Significant efforts have been expended by USRA and others in supporting NASA planning 
for the development of the appropriate information system for science in the Space Station 
era. This planning activity is continuing. 

3.0 TECHNICAL SUMMARY 


The TTPP is based on a concept evaluation methodology using a user-oriented rapid- 
prototyping testbed environment. State-of-the-art technologies and concepts are 
prototyped for the purpose of evaluating those concepts in a realistic setting. The aim is to 
evaluate requirements and concepts, as opposed to hardware and software 
implementations. The environment is user-oriented, meaning that the focus is on the role of 
such technologies in supporting evolving modes of scientific research. It is not a single 
testbed, but rather multiple experiments, each emulative of science in the Space Station era. 

During the past quarter, significant progress has been made towards the goals of the TTPP. 
The university activities are beginning to yield results, as evidenced by the presentations at 
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( Tec m hno , o v he d h ? ' 9 ' J he *** Coord,nat ors for each of the scientific disciplines 
Li Mfr Eitnh Systems S ^ ience ’ Microgravity Sciences, Astronomy and Astrophysics 
and Life Sciences) have each been working with their respective colleagues in thos e P X 
disciplines to articulate the unique requirements of that discipline with respect to future 
information system requirements. Following up on the previous quarter’s activities the 
various university testbeddmg subcontracts have focused on such unique requirements. 

forw^d* 0 ^^ ^° rtS ^ Un< ^? r ^* n ^ thC Vari ° US disci P ,inc Cities have moved 

^wLvh»I JSR h e f B,t t0 C ° P 3 COmraon Telescience Workstation Environment 
L !n • f Hi ? reSuhed m an initial release of the environment, which has been distributed 
c • m ^ r ® ste All sites now (or shortly will) have connection to the NASA 

Science Internet, thus facilitating communications and information exchange. 

In Section 4, summaries of the activities are given for each of the science disciplines 
prepared by the Area Coordinators, This is followed in Section 5 by the quarterly reports by 

tested acti T erSUy SUb f C °f r r r ' ReSUltS ** beginnmg t0 surface from the various 
testbed activities , some of which are written up in the area and subcontractor reports In 

particular, the reports by University of Colorado and University of Arizona have initial 

discussrons of lessons learned. The effects of networking on the Astronomy and 

As ophysics community are discussed in that area report (and also in the last quarterly 
report.) ■ ■ 

No significant problems have been encountered in completing this effort. 


4,0 AREA QUARTERLY REPORTS 


4J EAR TH SCIENCES - Jeff Star 


The TTPP-ES group consists of: 

Purdue University 

University of California, Santa Barbara 
University of Colorado 
University of Michigan 
University of Wisconsin 


ZHTTJ m W ° rk ° n "" P robleras and opportunities of telescience by considering an 
integrated field experiment. The scientific rationale behind the field experiment is to 

examine a spec.fted test site on the earth's surface, from the viewpoint interface Stween 
vegetation and biogeochemistiy. The near-term goal of this fieldexperimen. is to exercise 
conce P‘’ ’° SK What ca Pab>Uities are truly required that are not now 
$ ailable. Based on discussions with the team, the proposed field experiment is planned for 
the summer, and may involve more than a single field site. P 
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Following the discussions described in the last quarterly report to identify a specific set of 
science objectives for the field campaign, the Earth Sciences group met at Boulder on March 
9, 1988. The general research topic, as a focus for the field experiments, is vegetation’s 
role in global cycles. The long-term objective was to assist in identifying the types of data 
sets which will be needed for broad studies of vegetative coverage in global programs, such 
as the IGBP. The near- term goal was to identify one site and a set of specific tasks which 
will make a substantive beginning in addressing the long-term objective, and which can be 
accomplished this summer as a collaborative effort by the current TTPP Earth Sciences 
participants within the available resources. It was envisioned that some aspects of the four 
M’s (Measurement, Mapping, Monitoring, and Modeling) would be included. There was 
considerable discussion of potential sites, including: 

1. the Oxnard Plain agricultural region (arid but irrigated orchards and truck crops); 

2. the Burton Mesa oak woodland; and 

3. the Tippacanoe County cultivated croplands and timber. 

There were initial discussions of the measurements, data sets, models, etc., which would 
be needed. Two alternative approaches were discussed: 

1. the classical measuring and mapping approach, showing how these data feed into 
current models; and 

2. an emphasis on biomass, examining the correlation between greenness and what 

is seen on the ground, and tying these variables to current hydrologic, nitrogen cycle, energy, 
and other models. It was decided to concentrate on the classical measuring and mapping 
approach. 

At the end of the meeting it was decided that the UCSB and Purdue members would provide 
the primary scientific leadership and content. Colorado/LASP is prepared to provide access 
to the historical data sets and operational support from the SME instruments to obtain new 
data, with emphasis on ozone and other data which may be useful in making atmospheric 
corrections applicable to the other data sets. Colorado (Chase, et al) will be able to provide 
support in use of the HRPT data. Wisconsin is prepared to provide historical 
meteorological data by extracting selected portions of the operational satellite data. These 
would include soundings, cloud cover, rainfall, etc. UCSB is prepared to provide access to 
their library of LandSat image data and related online databases. 

Identifying the science tasks has proven to be difficult. The broadly based and integrated 
objective described above would demand a substantial amount of inter-laboratory planning 
and coordination. The problem (and lesson learned) is that it is very difficult for practicing 
scientists to take the time from their current work which is required, in order to plan and 
execute a new task on short notice. In recognition of this problem, we have changed our 
approach. The collaborators are presently defining individual science tasks which are 
locally oriented. They will, however, continue to work toward the general objectives 
outlined earlier. Cross-linking arrangements will be made to give each participant the 
benefits of easy connectivity, which is the hallmark of the telescience testbed project. 
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4.1.1 Purdue University 

The SUN 3/60C has been installed, and connected to the Internet, with a domain name of 
dur^^March 111 ^ ^ ^ After Solving har<3ware problems, Oracle was installed on the SUN 

7 n 8 ^ T m ^ e f byte WORM ° ptical disk during March from Arc Laser 
Optical Technology (ALOT). The software that came with the system will only allow one to 

copy an entire volume (floppy disk or disk drive), not a file or folder to the optical disk. 
Therefore, if the file(s) being copied do not fill the entire disk that they are on, a lot of space 
is wasted on the optical disk. ALOT is upgrading the software to allow one to copy a file or 
a folder at a time. They hope to have the new version of the software done in early June. 

A prototype of the Spectrometer/Multiband Radiometer Database catalog has been 
developed using Apple's HyperCard. The prototype was demonstrated at the Telescience 
meetings in Boulder, Colorado, during early March. The Field Research spectral database 
catalog stacks are available to anyone who would like a copy. The eleven files that 
e ine t e cat og for the spectral database have been loaded into Oracle on the SUN 3/60. 
The interface for the user is now being implemented. 

During April we successfully accessed BROWSE via a 9600 baud dialup using the US 
o tics modems. The session went much better than any connection we have had via the 
Internet and, of course, better than the slower dialup speeds. 

During May. we received the latest copy of the McIDAS PC software, which requires only a 

pr?a°T “ aCCeSSing “ d dis P la >' in 8 GOES imagery. The system works well on 
our IBM PC/AT system. 

4.1.2 University of Colorado 's OASIS 

We have been working with Elaine Hansen and Alain Jouchoux to obtain a copy of OASIS for 

S ° lar Mesos P here Ex Plorer satellite. The system that we are 
gouig to mstall OASIS on is a VAXstation 2000 which arrived in April. However, some of 

“7 7 U 1S missm §\ As of the end of May, the software still had not arrived from 
C. After the software arrives and is tested, we will obtain a copy of OASIS from the 
University of Colorado to install on the VAXstation. 

4.1.3 University of California , Santa Barbara 

The TTPP-ES splinter meeting on 9 March ’88, in Boulder was extremely helpful. At this 
meeting we reviewed our progress towards our respective goals, and discussed our 

respective interests and preparations for the proposed field experiment. We continue to 

work with the rest of the team in this regard. 

One of the experiments we have attempted involves a 9600BPS dialup line modem, which we 
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have borrowed from Purdue. In the past, we have been unsuccessful accessing one of 
VAXen through this modem at speeds above 1200bps. After discussions with the 
manufacturer, we finally have been able to provide 9600BPS dialup service from our 
BROWSE testbed to the Purdue team. Based on this experience, we have asked the TTPP 
to purchase a pair of Trailblazer-compatible modems for our field experiment.experience. 

Our local science scenarios involve problems of real-time spatial data acquisition and 
modeling. One of the projects involves numerical models of wildland fire behavior. We have 
developed a scenario, based on these models, which may be of value in understanding the 
spread of fire so that the remotely sensed data can provide a useful input to the fire fighting 
crew. We have had discussions with local Forest Service officials, and they are working on 
our concept with us. 

As reported at the TTPP meeting in Boulder, we are working on a data flow exercise, in 
which data residing on a several computers is accessed from a remote terminal (which 
emulates a portable PC in the field), and processing capabilities on several computers is 
used to help solve the problem. We are using a PC/AT with graphics terminal emulation 
software at the user end of the chain, and three VAX computers (involving both the VMS 
and UNIX operating systems). The network connections tested include both dialup and 
hard-wired access from the PC/AT (1200 and 2400BPS dial, and 9600BPS wired) 

We have run several tests to asses the performance and reliability of this data transfer and 
processing problem. The general flow of information involves: 

1. requesting data from a database node (UCSB BROWSE Testbed) transferring an 
image subscene to an image processing system (MicroVAX ERDAS); 

2. transferring data to a statistical processing system (S, running under UNIX on a 
VAX 750); and 

3. transferring results back to the PC/AT for further examination by the user. 

The first transfer experiment works, and we are examining several enhancements which: 

1. include additional processing nodes; 

2. include additional data types; and 

3. exercise a scientific scenario which interests the Forest Service. 

The second build of the Browse Testbed is now in an alpha-test stage. The principal 
developments in this area include: 

1. a hierarchical vector database structure; 

2. better use of graphics; 

3. higher effective performance; and 

4. a greater array of image data types. 

During the next quarter, we anticipate mounting the new software build in a public account, 
providing a new revision of the user manual to the TTPP-ES team, and encouraging the 
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* ea ™ t0 USC ^ cominent on the testbe d. We lo °k forward to similar exchanges with the 
SME database at Colorado and the spectral database at Purdue. 

4.1.4 Laboratory for Atmospheric and Space Physics, University of Colorado 

The primary objective of this task is to establish and exercise a capability so that others 
may access the LASP SME data, and for us to access their databases. The SME MENU 
system in on-line and available for use. A preliminary set of documents for guiding other 
consortium users is available, and will be distributed in the next few weeks. This material 

will be reorganized and prepared in the form of an integrated final users guide during the 
coming quarter. 6 

Preliminary information on the use of the UCSB BROWSE system was received earlier from 
Jeff Star. We believe that we will be capable of working with that system. Arrangements 
have been made to receive IBM-PC software for working with the McIDAS data received 
from the University of Wisconsin. That will be put online during the next quarter, and 
s ould give us the ability to acquire and use the NOAA operational satellite data, 

4.1.5 University of Michigan 

The REMOTE COACHING system is steadily improving in its capabilities. Some rules 
have been found to be incorrect and more video pictures have been needed to make it clearer 
for the users in the Space Physics lab. The current version of the system is being used for 
maintenance of an interferometer. However, the final version of the system will provide 
three modes of operation. The inquiry mode is used by the uninitiated user to learn about the 
operation of the instrumentation used in the experiment. In maintenance mode, the user is 
guided through a sequence of steps to perform some maintenance task. The diagnostics 
mode is used to determine the cause of a failure in the system. 

All three modes provide an option to stop the current operation and establish a 
communication link via modems with the real expert at the local control station (back at the 
university). After establishing the communication link, the COACHING system at the local 
site is brought up to a state of operation identical to that of the remote site. The concept of 

state for the expert system means the activation of the same rule, the same agenda and the 
same facts. 

Since the modems have not yet arrived, we have not established communication between 
the remote systems at the Space Physics Laboratory and the local system at the Robotics 
Lab. However, we have temporarily set up a communications testbed within the 
laboratory. We are developing the communications software with this testbed while 
waiting for the modems to arrive. With this testbed system we have solved the problems of 
capturing a picture a the remote site, compression of the image, transmission to the local 
site, decompression and display on the SUN video monitor. 

4.1.6 University of Wisconsin 
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Telescience efforts at the University of Wisconsin have resulted in advances in two main 
areas during the past three months: 

1. improvements in IBM PC software designed for the reception; and 

2. display of McIDAS data products, and a connection to the Internet. 

We have modified our version of IBM PC Mcldas software, such that only a color video 
monitor is necessary for accessing and displaying GOES visible, IR, and water vapor 
imagery. The package uses standard asynchronous dialup to access the McIDAS 
database. The software also includes a scheduling option to allow automatic access of a 
time sequence of images useful for cloud animation. The software is available upon request 
to TTPP participants, and has been distributed to Purdue, UCSB, and to the University of. 
Colorado- LAS P. We are awaiting feedback from these users. 

We recently made connection to the USAN ethemet (NSFnet) in our building, using an IBM 
AT that will be the foundation of a McIDAS bridge. Our new host name is 
"McIDAS.ssec.wisc.edu" and is at IP address 128.1 16.12.97, at this time. Testing of email 
operations, using the USAN connection, has revealed a number of reliability problems. We 
suspect that the problem lies in the mail relay host, and are continuing to work the problem. 


4.2 LIFE SCIENCES - Larry Young 


The Life Science Telescience users, represented by researchers from ARC, JSC, KSC and 
MIT, produced an overview of the special requirements of the Life Sciences Community for 
Telescience for presentation to NASA Headquarters representatives. The most immediate 
output was the "Life Sciences Advocacy Report" issued in May 1988. As interest in the 
Telescience community increases, particularly among the international partners in Space 
Station, the need to work on requirements and standardization of everything from video 
formats to data streams is becoming apparent to all. 

The major direct progress on the Life Sciences portion of the TTPP was the completion of the 
video link from KSC to MIT, the training of the astronaut surrogate and sled operation team 
at KSC by the MIT investigators, and the preparation for running the formal testbedding 
experiments during June and July. 


4.3 MICROGRAVITY SCIENCES - Dick Hahn 


Rensselaer Polytechnic Institute is concentrating in the area of microgravity materials 
science with the cooperation of the Microgravity Materials Science Laboratory at Lewis 
Research Center. Efforts this period were directed toward the finalization of the necessary 
communications/control hardware, experimental equipment and coding of the necessary 
software. Significant progress has been achieved is these areas and we plan to attempt 
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remote control at MMSL during the next quarter. 

The University of Arizona has made good progress with development of a remote fluid 
handling the testbed in support of the microgravity and life sciences. Design of the software 
for the man/machine interfaces has been finalized. Coding and testing of the software is 
underway, and should be completed by next month. Necessary modifications to the 
electrophoresis and pH instruments were also finished, and evaluation of the three alternate 
injection mechanisms is well undenvay. It is anticipated that the phase one testbed will be 
completed and demonstrations scheduled by the end of the next quarter. 

4.4 ASTRONOMY AND ASTROPHYSICS - David Koch 


The first table presents a summary of the network connections that the individual 
investigators are using. In some cases, not all of the connections for a person’s institution 
are shown, since they may not be utilizing every network for their TTPP activities or may 
not have access, even though the network does exist on campus. Current connections are 
shown with a C and future connections are shown with an F. 

The bottom line from the experience of the astronomy Pis is that for email, the networks are 
adequate, but for most other functions they are woefully inadequate. Specifically, the 
measured transfer rate for files is typically on the order of a kilobyte per second. Commonly 
available modems are an order of magnitude faster and for this reason, as can be seen from 
Table 2, most Pis have and use faster modems for this purpose. Unfortunately, it will 
probably always be true that the users will fill the available network capacity, whatever it 
is. The situation is somewhat better for performing remote logins. On SPAN, it seems to be 
fairly good. Not only is it possible to have good connectivity within the U.S ., but also to 
computers that are on SPAN in Europe. However, on the other national networks the 
reliability is poor, both in terms of getting access and in having a sufficiently long connect 
time without getting dropped, that is for a fraction of an hour to several hours. Hopefully, for 
TTPP users this will improve with NSN providing TCP/IP for non-DEC machines. At 
present no network seems to be adequate for realtime instrument control. But it is too much 
to expect to have remote real time control, unless it is absolutely necessary for human 
intervention for performance of the experiment, which is unlikely in astrophysics, but not 
unlikely in life sciences, material processing, etc. For near realtime control, NSN or SPAN 
may be sufficient if the reliability can be insured at a 95% or so level for all time and that it is 
99-5% reliable for some part of any five minute interval, that is, in any five minute interval 
one should have connectivity for some portion of the five minutes. At present, the non- 
NASA national networks do not provide the needed reliability. In addition, for control which 
requires visual feedback, even with slow scan TV, the bandwidths are not adequate. In 
general, one would build the instrument controller at the instrument and use the network only 
for passing instructions to the controller and receiving housekeeping feed back from the 
instrument, that is, the traditional approach used to run any spaceflight experiment. Rarely is 
there a need in astrophysics for realtime response by the observer. 
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NETWORK CONNECTIONS USED BY TTPP 



NATIONAL: 





REGIONAL: 


ARPA 

SPAN 

NSN 

BITNET 

UUCP 

PSDN 


Ames 

c 

c 





C-BARRnet 

AZ, Astro. 

c 


F 

C 



C-56K to JVNCC 
F Westnet 

AZ, Eng. 


c 

F 

c 



C-56K to JVNCC 








F Westnet 

UCB 

c 

G 



c 


C-BARRnet 

U of Colo. 

c 

C-56K 


c 


c 

C-56K? to JVNCC 

Cornell 

c 



c 



C-NYSERnet 
C-Tl to JVNCC 

U of \ID 

c 

G* 


c 



None 

MIT 

c 






C-Tl to JVNCC 
C-Athena 

SAO 

c 

C-56K 

C-56K 

c 

c 


C-Tl to JVNCC 


Legend ARPA 

- Actual includes ARPA, NSF, NSI and MILNET 



all on Internet, all TCP/IP 


SPAN 

NASA’s DECnet 


NSN 

- NASA’s TCP/IP 


C 

- Current connection 


F 

- Future connection 


G 

- Gateway through another site 


* 

- Still requires SPAN from USGS to Lowell Observatory 


JVNCC - John Von Neuman Computer Center 


Tl 

- is 1.4 MHz 



TABLE l. 
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The speeds for the networks other than SPAN and NSN are not shown, since no user can 
realize a significant fraction of the network bandwidth, whereas, on SPAN, NSN and regional 
network a substantial fraction of the bandwidth can be realized for short periods of time. An 
interesting observation is that many of the astronomy Pis have a high speed connection to 
JVNCC, however, this connection is intended for JVNCC access, not to network remote 
users to each other. 


DIALL P/DEDICATED CONNECTIONS 



DIALUP 

DEDICATED 

FUTURE 

Ames 
AZ, Astro. 

9600: general access 

17K: UA to Kitt Peak 
9600: data acquisition 
UA to IP AC database 



AZ, Eng. 

9600: UA to Thaw for 

Campus video: 



telescope control 

visual feedback of 
remote fluid 
experiments 


UC Berkeley 

1200/2400: login 
file transfer 


9600 dialupor direct: 
instrument control 

U of Colorado 

2400: telescope control 

Campus video: 

Satellite: 

Cornell 
U of Maryland 

slow scan video 

CCD data transfer 

telescope control 

MIT 

2400: telescope control 


17K & T1 potential: 
campus to telescope 
CCD data transfer 

SAO 

2400; general access 
IR image transfer 

T1 UA/Mt. Hopkins: 
s/w maintenance 



TABLE 2. 


Many of the Pis have installed either high speed dialup modems or have a dedicated link for 
performing some of their activities. These connections are identified in Table 2. 
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NATIONAL NETWORK USAGE 


L 



EMAIL 

FILE TRANSFER 

REMOTE LOGIN 

Ames 

few kB per day 

occasional 

occasional 

AZ Astro 

few kB per day 



AZ Engr 

few kB per day 

occasional 

occasional 

UC Berkeley 

few kB per day 

several MB several 
times per week 


U Colorado 

few kB per day 



Cornell 

few kB per day 

gave up on trying 
routine transfer of 




large files 


U Maryland 

few kB per day 



MIT 

quite frequently 

less than 5MB 

occasional 


each day 

per day 


SAO 

tens of kB per day 

occasional 

continually for 
remote software 
maintenance and 
development 


TABLE 3. 


These dialup or dedicated links are used for one of two reasons, either to go where no 
network has gone before or because the existing network capabilities are inadequate. More 
about this later. 

By now, each of the Pis has gained some experience in use of the networks in some way or 
another. All of them have made use of electronic mail (email) simply by virtue of 
participating in the TTPP. The use of email has been both via dialup and via the network. 
NASArnail (a subset of Telemail) can be used both ways. The mail facility, as part of Unix 
or VMS, makes use of the network. The networks are also being used to perform the TTPP 
objectives. The usage is shown in Table 3. 
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national network performance 


EMAIL 

FILE TRANSFER 

REMOTE LOGIN 

INSTRUMENT CONTROL 

Internet 

Good 

Inadequate: 
Rate too low 
for large files. 

Marginal: 
Drop connect 

Inadequate: 
Unreliable 
Latency too long 

SPAN 

Good 

Inadequate: 
Rate too low 
for large files. 

Good 

Inadequate: 
Unreliable 
Latency too long 

Bitnet 

Good 

Inadequate: 
Rate too low 

Marginal: 
Drop connect 

Inadequate: 

Unreliable 


r T N fi!i n °J mstaUed Wldely enou S h to have performance results. Typical transfer 
ates are lkbaud on national networks. Regional or campus networks are not included since 
m general they have T1 bandwidth and are good or adequate for nearly all purposes 


TABLE 4. 


The usage shown may be slightly biased, since after attempting to perform a function several 

tunes over the network with constant failure, the user probably has given up and tried an 
alternate approach. r 

The results from the network usage are shown in Table 4. Accurate quantitative measures 
of performance are generally not available and would require many controlled experiments. 
Those types of studies are better left to computer scientists. Rather, the perfonnance is 
ased more on a qualitative measure of whether the network served as a beneficial resource 
or a stumbling block based on the types of scientific activities that are performed on a day- 
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All in all, the biggest difficulty is that the network bandwidth is too low and unreliable to 
perform most of the science functions envisioned. Recall that one of the major objectives of 
the overall TTPP was to determine the network communications requirements for performing 
telescience in the Space Station era. A big plus for all of the Pis is that they have all 
become use to using the networks for email and the exchange of information with each over 
the network. This has definitely improved the individuals productivity. This summary should 
provide a good foundation for evaluating the capabilities of the current networks for 
performing telescience and for providing a basis for the definition of requirements for the 
future. 

Recommendations (Wish List) 

Based on the TTPP experiences to date, the following wish list of recommendations is 
provided to help to improve the capabilities for telescience in the Space Station era: 

1. Increased reliability and bandwidth: to be included with NSF backbone at T1 
but still inadequate for interactive image processing or other functions requiring high 
realtime bandwidth such as interactive realtime instrument operations. Bulk data 
distribution will continue to be done on hard media. 

2. Good directory of addresses/universal mailer: very often one wants to use 
email but has no way of determining the correct address. An intelligent mailer that could 
find people, much like AT&T directory assistance (given a site and a person’s name, find 
his email address) would be helpful. 

3. Routing: although a site may be connected via a network the local routing 
controls the link to the next site, ways of determining and defining the Internet route should 
be available to the user. 


4.5 TECHNOLOGY - Barry Leiner 


The TTPP involves the use of advanced technology and its role in supporting future scientific 
requirements. The above sections summarize the various subcontracts from the 
perspectives of the space science disciplines. However, some of the explorations provide 
more general functions and are best viewed as underlying technology. In this section, a 
summary of these activities is provided. 

4.5.1 Networking and Communications 

As reported last quarter, network performance continues to be of major concern. The report 
of the Astronomy and Astrophysics community above well illustrates the issue. While the 
current networks are capable of providing adequate performance when lightly loaded, the 
usage of the general purpose networks (such as NSI) is high and increasing. Significant 
planning and engineering effort must be initiated to assure that the needed network 
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performance will be available. 

It should be noted that, at the recommendation of the White House OSTP, the Federal 
research agencies (DARPA, NSF, NASA, HHS, and DoE) have joined forces to 
aggressively pursue the evolution of networking to multi-megabit rates and well beyond. 
(NSF and DARPA are pursuing an initiative to develop gigabit speed networks). This 
activity is expected to significantly alleviate the bottlenecks currently being experienced by 
the science community. 

Details of networking experiments may be found in the reports of Section 5. We plan to 
summarize these results in the contract final report. 

4.5.2 Workstations 

University of California, Berkeley demonstrated the remote commanding of an EUVE 
prototype instrument at Berkeley from a workstation at the TTPP meeting at Boulder using 
the NSI. This was augmented by compressed video transmission to allow video monitoring 
of the instrument. 

Tests of a WORM optical disk drive at Purdue University have indicated a problem with the 
file copying software; that the software only allows copying of an entire volume rather than 
per file or folder. Enhanced software is expected to be released in early June. 

Stanford is exploring the use of TAE for workstation monitoring and control of spacecraft. A 
demonstration instrument interface based on TAE was received from GSFC and brought up 
on a Sun 3/260. 

4.5.3 Software Environments 

The TAE Plus (Transportable Applications Executive plus X- Windows) is being explored by 
the University of Arizona as a development package for building a user interface for a SIRTF 
observer. 

The University of California, Berkeley, has determined that a new product by Sun 
Microsystems (Network Software Environment) is related to the Berkeley Software Control 
System effort. However, it appears that NSE will not provide the required support for 
collaboration by distributed groups. Berkeley is investigating how their efforts in this area 
can be applied to NSE. 

4.5.4 Teleoperations 

The University of Arizona, Astronomy has had some moderate success in transferring image 
data from an infrared array camera using 9600 bps modems over telephone lines to support 
quick look analysis at a remote site. 

The University of Arizona, Engineering and Mines has been investigating remote operations 
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for fluid handling and has considered a number of maintenance issues and testing procedures 
for failure modes. 

The University of Colorado, LASP efforts on OASIS have continued. Porting of OASIS to a 
Sun environment has been initiated. Coding of a prototype of an OMS has been completed 
and testing is to begin shortly. 

The University of Arizona, Engineering and Mines has continued its investigation of the use 
of OASIS for teleoperations and the role of the user interface and CCSDS communications 
protocols. Recent work focussed on the multiple session problem, where non-controlling 
remote sites can view data. 

The University of Michigan is continuing its experimentation with remote coaching. The 
system is being enhanced and validated simultaneously using the rapid-prototyping user- 
oriented testbed approach, working with users in the Space Physics Lab. 

4.5.5 Teleanalysis 

University of California, Santa Barbara, has been investigating data flow in a distributed 
environment, using a remote terminal to access data residing on several computers. They 
have been investigating operation at multiple interconnect speeds. 

The BROWSE testbed at University of California, Santa Barbara is now in the alpha-test of 
its second build. This second build represents a number of technical improvements. Tests 
are planned using data from SME/Colorado and the spectral database at Purdue. 

The University of Rhode Island has discovered that the simple image compression strategy 
of just sampling to send quick look data appears to work quite effectively. 


5.0 SUBCONTRACTOR QUARTERLY REPORTS 

5.1 UNIVERSITY OF ARIZONA, ASTRONOMY 

Institution: University of Arizona (Steward Observatory) 

Principal Investigator: Dr. Erick T. Young, Fourth Quarterly Report prepared by Irene 
Barg 

Network Connections: Internet, BITNET, SPAN 
Email Address: eyoung@solpl.as.arizona.edu 

Telescience Workstation: Sun3/160C, 141 Mb hard disk, 1/4 inch tape drive, sharing 
hardware and software resources with a MicroVAX II and a Sun 3/150C within the infrared 
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group. The workstation is connected to the Steward network, which gives us access to the 
campus network. 

Operating system: Sun UNIX (V 3.5) 

5.1.1 Hardware Status 


Workstation 


The telescience Sun 3/160 experienced sporadic re-booting problems the past several 
months. After much testing, installation of a replacement CPU board solved the problem. 
We continue to share hardware resources within the infrared group at Steward. Via the 
Steward network, we mount the IRAF package which resides on a Sun 3/150 and most 
image files are stored on the MicroVAX 0. Even with this sharing of resources between 
computers, the Mb hard disk is too restrictive for loading and testing the various available 
software (i.e., TeleWEn and TAE Plus). Now that the workstation has stabilized, we plan 
to purchase a Mb hard disk to relieve the disk space crunch. 

Modems 


The three U.S. Robotics Courier HST 9600 bps modems have been used for two functions: 

1 tra n sf er of raw data from the Steward HgCdTe array camera from Kitt Peak to a 
computer on campus for "quick-look" processing. The data rates available with the 9600 
baud modems over commercial telephone lines are adequate for this task; and 

2. remote access to the IPAC database. The modem connection to IPAC even at 
rates below 9600 baud have become more desirable than utilizing the existing networks (see 
Communications Status for more information). 

5.1.2 Software Status 


The IRAF package is currently mounted on the telescience workstation from another Sun 
computer within the infrared group. IRAF has been used for image display and other 
statistical analysis of the raw data produced from the Steward Observatoiy HgCdTe array 

camera. Format conversion to FITS for archiving the raw camera data is performed before 
file transfer takes place. 

The TAE Plus Prototype Version 3.0 was installed on the telescience workstation along with 
X-wmdows. TAE Plus is currently being evaluated as a development package for building a 
user interface for a hypothetical SIRTF observer. Concepts being investigated are: 

1- status of the remote observing facility; 

2. scheduling of remote observation requests; 

3. expert systems to provide assistance to the observer in developing an observation 
request; 
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4. the ability to do graphical "quick-look" analysis of raw data after an observation 
run; and 

5. access to archived data. 

5.1.3 Communications Status 

The telescience workstation is connected, via the campus network, to the Internet and 
BITNET, and is soon to be connected to NSI and WESTNET. Communication experiments 
with the Cornell TTPP group and IP AC had different results. Network connections from 
Arizona to the West Coast Region (i.e., to IP AC or Berkeley) are more difficult than network 
connections to the East Coast Region (i.e., to Cornell or Columbia). It is believed this is 
due to routing. A transmission to IPAC goes through Arizona’s JVNC gateway (a satellite 
link to the Princeton Supercomputer Network) then rerouted to its destination. This makes 
interactive use of the IPAC computers painful. Subsequently, the 9600 bps modems were 
put in place for communications between IPAC and Arizona. 

Network communication experiments with the Cornell TTPP group have been more 
successful. File transfer, using FTP, for files less than 100K work well, and interactive use, 
using telenet between computers is adequate. File transfer of files larger than 100k become 
unreliable, and most of the time impossible. (See Cornell’s TTPP April Monthly Report for 
file transfer rates between Cornell and Arizona). 

5.1.4 Continued and Planned Activities 

Remote Observing 

For most astronomers, telescience will not mean tele operations of a remote instrument. One 
value of telescience concepts will be in the ability to remotely request and plan observations, 
check on mission status, receive processed data products, and gain general access to and 
share astronomical data. The Space Telescope Science Institute has implemented the 
Remote Proposal Submission System which allows submission over the telenet packet 
switched network. As mentioned earlier, using the TAE Plus package, we plan to build a 
user interface for a hypothetical SIRTF observer. Concepts to be investigated are remote 
observation request, review, scheduling, and the dissemination of the data. 

Remote Operation of an Infrared Array Camera 

One of the goals of the first year was to investigate the transfer of image data from an 
infrared array camera to a remote site for quick-look reduction analysis. We have had 
moderate success using 9600 bps modems over telephone lines. Additional control functions 
are needed to approach true remote operation of the camera. 

Once completely ported to the Sun, the OASIS package may be installed on the current 
telescience workstation, pending additional hardware and software requirements. 
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5.2 UNIVERSITY OF ARIZONA. ENGINEERING AND MINES 


5.2.1 Programmatic Summary 

This is the Spring quarterly report for the astrometric telescope, remote fluid handling and 
technology development projects at the University of Arizona. It does not include the’ 
University of Arizona involvement in the SIRTF project. 

Telescience research can be split into two main areas: 

1. remote control, sensing, manipulation, etc.; and 

2. remote data storage, retrieval, etc. 

The goals of our two telescience testbeds are related to area one above. The first testbed 
involves teleoperation of the Thaw astrometric telescope, which is a forerunner of the 
Astrometric Telescope Facility (ATF) to be attached to Space Station. The second involves 
development of systems and software for Remote Fluid Handling (RFH) in support of the 
microgravity and life sciences. These seemingly quite different testbed demonstrations were 
selected to pursue the following goals in our research: 

1. design of a set of modular tools to allow teleoperation of scientific experiments. 
These tools include the man/machine interface at the remote commanding computer and the 
machine/machine interface between the remote commanding computer and local controlling 


2. generic design of these tools so that they are easily applied to various Space 
Station experiments that scientists will control from their home research sites. 

3. evaluation of time delay effects on teleoperations over packet switched computer 
networks using the NASA Science Internet (NSI) as an example. These results will then be 
extrapolated to include uplink and relay satellite delays. 


TTie attainment of our first two goals can be measured through the usefulness and similarity 
of the tools resulting for the two distinct testbeds. The attainment of our third goal will be 

accomplished by quantitative and qualitative means when the NSI connections become 
available. 


Several maintenance issues have also been considered: 

^ ATF testbed, calibration sequences and other self-test sequences for ensuring 
the proper operation of the instrument. 

2. AFT testbed: emergency procedure in case of external interrupts, e.g., the 
approach of a shuttle (the telescope must be closed). 
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3. ATF testbed: remote login for software maintenance. 

4. RFH testbed: calibration sequences and other self-test sequences for ensuring 
the proper operation of the robot. 

5. RFH testbed: replacement of instruments in the rack by shuttle crew. This is 
necessary since some instruments will be specific to a particular experiment and will not 
remain in space for the entire life cycle, and since other instruments may be replaced by 
newer versions. 

6. RFH testbed: uploading of new software modules, and installation in the local 
control computer from a remote location, remote login and editing; and software self-tests. 

The following failure mode testing procedures have been developed: 

1. ATF testbed: failure modes are investigated by simulating randomly occurring 
failures at the experiment site, while an operator is teleoperating the experiment from the 
remote commanding computer. This failure analysis is an intrinsic part of the Thaw telescope 
simulator. 

2. RFH testbed: no special provisions are necessary. Failures occur naturally, i.e., 
a syringe rolling off the table, or the HERO robot trying to commit suicide during a power 
outage (!) Such failures are being handled by teleoperations whenever they occur and 
provisions are foreseen to prevent repetition (if possible). 

5.2.2 Astrometric Telescope (Astronomy and Astrophysics) 

Good progress has been made on the astrometric telescope testbed since the last report. 

The major results that were obtained are: 

1. The design of the user interface for the remote telescope control testbed has been 
completed (senior project report of Steve Gates). A preliminary working paper can be made 
available to interested parties now, and a final version will be available as a TSL report 
shortly. 


2. The coding of the new Oasis application database for the remote telescope control 
has been completed including all menu items, command functions and display windows. 

3. Not yet completed are the communication interface using the CCSDS protocol, the 
handling of incoming textual information, and the handling of incoming bitmaps for display in 
an Oasis display window. Also not completed, is the mapping of incoming finderscope and 
guiderscope data into appropriate display windows. This will be our primary activity during 
June. 


4. Basically, the Thaw telescope simulator has been completed. All commands are 
now correctly scanned, parsed, and processed. 


- 19 - 



TTPP Fourth Quarterly Report ( M88.4 ) 


June 1, 1988 


5. We are currently working on a failure simulator. The idea is as follows: we will 
use a random number generator to draw uniformly distributed random numbers between 0 
T u Ff! each ^ comm g command, we will draw one random number, and compare it with a 

. CS ° C I ’ 11 2L Can ^ USer Specified ' If the ^ number is above the threshold 
the command will be processed incorrectly (e.g„ it will be processed correctly, but the ’ 

acknowledgment message is never sent back, or an acknowledgment message is sent back 
but the command has not been properly processed, etc.) We want to use this failure 
thT!i f°i °f purposes. A remote experiment commander who is not familiar with 

ir f ^ failure modes wUI have t0 out what went wrong, and will 
have to think of a way to fix the problem. A side effect of this failure simulator will be that 

we will be able to learn which types of problems can be fixed with the current user interface, 
and where we still need to augment the user interface. 

6. We are also still working on a complete set of safety checks. The local controlling 
computer will have to scrutinize each incoming command to see whether it is potentially 

development 116 ChCCkS haV6 alrcady 136611 built uito th e simulator, but this is still an ongoing 

Additional details on these items are contained in the technology section (5.2.4) of this 
report. 

5.2.3 Remote Fluid Handling (Microgravity and Life Sciences) 

Software Issues 

^ mterf3Ce f ° r the remote fluid hmdl ™Z laboratory has been 

pleted. The interface is primarily menu driven and is simple enough that a novice user 
can operate the laboratory, but it is also detailed enough to take advantage of all the 

TSL-009/8 g UnCtl ° nS ' This work has 136611 documented and is available as technical report 

TTie machine/machine interface design has also been completed. It includes communication 
between the remote command computer and the local control computer for enabling data 
transfer .controlling the robot, and interacting with the various instruments in the laboratory 
I his is documented in technical report TSL-006/88. 7 

^^^omD t ^ted° I ^ Ut H r/ ^ Stmme 4 lt ilUerfaCe f ° r rem ° te fluid handling labora tory has also 
been completed. The document does not list the exact commands and programs which will 

constitute the interface, since these will need to be changed as the equipment changes 

However it does give a description of the required functions of the commands and programs 

which will operate the equipment of the laboratory. This draft is available as TSL-010/88. 

PCOTc^ Tf ^ S ° ft T, e PaCkagC WaS reCeived> inStalled - md test6d on ol " 

, , P J *' The tests cons,sted of the sample programs which were provided with 

e pac age, and all eventually passed. There was one problem detected with the test 
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program for the math library, but after calling the software support line, it was resolved. 
Evidently for 8086 processors, a parameter is required when linking programs which use the 
math library. Another problem was detected by Ames Research Center concerning low level 
I/O, but this problem has also been resolved. The ADA compiler will be used frequently in 
the next month for the implementation of the local control protocols for the remote fluid 
handling laboratory, and a more detailed review of the software will be available at that time. 

System/Hardware Issues 

In any microgravity environment, fluids must be handled in closed containers under pressure, 
with special attention paid to the avoidance of air-liquid interfaces. This technique has been 
demonstrated using remote robot control of an apparatus in which fluid was transferred by 
use of a syringe. The Scorbot robot arm has proven to be sufficiently accurate to introduce 
specially designed syringes into their also specially des gned receptacles for remote fluid 
handling. Double containment is being used anywhere. The syringe can be used to penetrate 
a septum to withdraw a fluid from a plastic collapsible bag, where the bag is contained in a 
standard test tube. 

Operation of the syringe adapter for fluid handling by the Scorbot has indicated the need for 
incorporating safeguards against breakage of needles. The problem will be more pronounced 
when the operator is in the robot control loop. Then, inaccuracies in positioning the end- 
effector may result in misalignment of the syringe adapter with the hole in the fixture. Two 
possible solutions are: 

1. an end-effector equipped with a force sensor that will detect excessive force of 
contact and signal the robot to discard the syringe with the damaged needle; or 

2. coordinated control of a vision system and the robot, to detect and correct 
misalignments before the needle comes in contact with the fixture. 

Our recently acquired vision system (obtained from separate funds), which was not available 
to the telescience project until now, will provide us with the opportunity to experiment with 
the latter solution. 

As an alternative to the inhouse-designed syringe driver assembly, a battery-operated 
motorized pipette, recendy introduced to the market by the Rainin Instrument Co., was 
ordered and has been received. This pipette uses disposable tips and is equipped with a 
mechanical tip ejector. This feature is one of the advantages of the pipette over the syringe 
assembly, where a contaminated syringe must be disposed of rather than the tip. Also, the 
digital pipette lends itself well to direct computer control of the fluid volume in the tip and 
simplifies the robotic tasks. It is hoped that the use of this device will eliminate the need for 
the syringe holder and fixture, will be more in line with the current industry trend towards 
fixtureless assembly, and will reduce the overall weight of the components used in the 
system. Since this pipette has been designed for use in ground-based laboratory work, and 
picks up fluids by creating a vacuum in a chamber above the disposable tip, changes will be 
necessary to prevent the fluid from floating up this chamber in reduced gravity. The current 
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thinking calls for using syringes with needles rather than the provided plastic tips where 
each syringe will be fitted with a plastic membrane attached to the spring. Then fluid 

pressure wiH push the membrane up in the syringe barrel and with enough surface tension no 
fluid will escape the sides of the membrane. 


A major modification to the electrophoresis instrument was needed in order to adapt the 
needle guide on the inlet ports of the instrument to conform to the accuracy of the robot. A 
tapered needle guide will provide the robot with sufficient flexibility during injection of 

^ 1 thC ^ apUlary tube 7116 fl o w -through pH-meter to be used in the demonstration 
will be fitted with a solenoid valve at its outlet. TTien, rinsing of the capillary tube is 

possible by send mg an appropriate signal from the controlling PC to shut offer open the 
valve. r 


Two of the available five timer/counters on the LabTender board have been used to trigger 
two of the available A/D channels, at desired times, under software control. For the 
electrophoresis device, a sampling period of one second is sufficiently fast, considering the 
s ow tune response. The counters can be used to provide sampling rates of up to 100 Hz. 
Since the pH-meter being used is a flow-through type, taking the average of a few (3-5) pH 
readings after injection of a sample provides a reasonably accurate pH value Online 
calibration of the instruments may also be needed, if signal drifting becomes noticeable. 

Future Plans 


During the TTPP II meeting held at Boulder, Colorado (March 7-9, 1988), several of the 
participants associated with NASA’s Ames Research Center (John Bosley, Vicki Johnson 
Arshad Mian, Daryl Rasmussen, and Chris Vogelsong) met with a number of participants ’ 
from the University of Arizona (Francois Cellier, Larry Schooley, and Don Schultz) to 
discuss topics of mutual interest. In particular, it was discussed whether and how far a 
cooperation between these two groups should and could proceed. 

It was concluded that a cooperation between the two groups on a number of different topics 
seems highly profitable to both groups. Such topics include: 

1 . remote robot control; 

2. fluid handling for the life sciences testbed; 

3. OASIS application development; 

4. man/machine interface; 

5. machine/machine interface; 

6. machine/machine communication protocol; and 

7. simulation. 


t was agreed that the University of Arizona will provide help to NASA for reproduction of 
part of the testbed environment that has been developed at the University of Arizona. This 
includes, in particular, the special syringes and syringe receptacles. These will be built by 
the University of Arizona for NASA. NASA may also decide to buy a SCORBOT robot and 
use it mstead of the HERO 2000 for their experiment. This would allow AMES to also copy 
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our robot control software. 

In order to intensify the information exchange between the two groups, the following 
provisions will be made: a graduate student at the University of Arizona (Jerry Hunter) has 
worked full time during the months of April and May 1988 in the University of Arizona TTPP 
project. His senior project was also in this laboratory (instrument rack design) and he has 
acquired detailed knowledge about our remote fluid handling testbed (in particular, the 
hardware/software configuration of the robot control environment, and information about the 
OASIS databases). He will work during the months of June and July 1988 in Daryl 
Rasmussen’s group at AMES to transfer the previously acquired knowledge to AMES, and 
to pick up new knowledge from AMES. He will then return to Arizona for the fall semester 
to bring his newly acquired knowledge back into Arizona’s TTPP project. 

Another meeting was held at the University of Arizona on March 24 and 25, to follow up on 
these discussions. Those participating were Vicki Johnson from RIACS, and Chris 
Vogelsong from Bionetics (both representing Daryl Rasmussen of NASA Ames Research 
Center), as well as, Larry Schooley, Francois Cellier, Don Schultz, Dick Mosher, Richard 
Bienz, Yadung Pan, Reza Fardid, Byron Hack, Alfie Lew, and Julie Willis from the University 
of Arizona. 

After extensive tours of the University of Arizona telescience project facilities and 
demonstrations of the major accomplishments, the meeting ended with a general discussion 
and summary. It was concluded that the agreements of the previous meeting had been 
reinforced, and that a cooperation between the two groups on the topics listed above would 
indeed be highly profitable to both groups. 

5.24 Technology 

By developing two separate and quite different testbeds in parallel, the University of Arizona 
team has already learned how to modularize the testbed environment in such a manner that a 
large variety of quite different Space Station applications will be able to profit from the 
testbedding activities. The results have already shown that the assumptions about hidden 
similarities between seemingly distinct remote control/sensing activities were indeed 
correct. These can be identified and utilized in a modularized experimental system design, 
with minimal change from application to application. It has already become clear how major 
portions of the technology development can be used in both testbeds. 

The man/machine communication interface (using OASIS) can be made sufficiently generic to 
be applicable to almost any remote control/sensing situation. Differences between various 
applications can be confined to the development of a new application database. 

The machine/machine communication interface (a command language used for the exchange 
of information among the remote commanding computer and the local controlling computer) 
can also be made sufficiently generic to be applicable to almost any remote control/sensing 
situation. Differences between various applications can be confined to the development of 
new scanner tables which are being automatically generated by a compiler-compiler out of a 
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user supplied generic data tablet. The communication protocol (using the CCSDS packet 
telemetry standard) can also be made independent of the application. 

Perhaps more importantly, each program module can be decoupled from (i.e., made 
in ependentof) the program modules to its left and to its right by appropriate data flow 
protocols. These protocols are designed in such a way that high-level user commands are 

successively reduced to sets of lower-level commands, at the expense of a higher data traffic 
through the communication link. 

Lately, we have been working on the multiple session problem, which can be described as 
follows: while one ground station (e g. one of the universities) controls an experiment 
onboard Space Station, the experimenter may need some advice, either from NASA or from 
some other scientists. Thus, tt seems desirable that, while one experimenter controls his 
experiment, others can observe what is going on. These others can be also groundbased, or 
they may involve Space Station personnel. 

For this purpose, we have introduced a "privilege key," which is maintained by the local 
controlling computer (onboard Space Station). An experimenter who is not in possession of 
this key can issue all SHOW"-commands and ”DISPLAY"-commands but all "SET" 
commands are disabled. Since only one key exists which can be assigned to any one of the 
potential operators, others can observe, but they cannot intervene. 

Any observer who has requested and obtained the privilege key automatically becomes the 
commander of the experiment. The local controlling computer keeps track of the experiment 
For each type of experiment, experimental actions will be defined, so that the local 
controlling computer knows at all times whether an experiment is still ongoing. If an 
experiment is interrupted, e.g, because the experimenter did not do anything for a predefined 
nmeout period, the local controlling computer will automatically take back the privilege key 
The same is trne if the connection is lost.. For each type of experiment, a set of emergency 
procedures wdl be defined which be executed by the local controlling computer after it forcibly 
takes back the privilege key (e g. due to lost connection). * 

Experiments can also be performed in batch (by using delayed commands). In which case 
the local controlling computer becomes the commander of the experiment, and will not sign 
out the privilege key until "his" experiment is completed. In order to avoid congestion, it is 
possible for the local controlling computer to maintain a sign-up sheet to reserve experiment 

There is one disadvantage to be noted for the above outlined procedure. In fact, the local 
controlling computer becomes a single non-duplicated resource. If the local controlling 
computer gets confused, and, e.g., is no longer willing to sign out the privilege key, we are 
stuck. For this reason, an override command will also be made available, which requires the 
knowledge of a password. This override command will never be used as long as the local 
controlling computer perfonns correctly. 

There is a need for the different observers and the commander to communicate with each 
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other. For that purpose, we need a mail facility, and eventually, a phone facility. It will not 
be feasible to rely on existing facilities as they are available, e g., for DECnetted VAXes. 
Instead, we need to map these facilities onto the communication protocol (CCSDS) which 
will be utilized for the remote control of the experiment. 

Currently, this seems to pose a certain problem, since the Oasis software has been equipped 
to receive telemetry information only. Presently, all incoming data for Oasis must be 
numerical data. Oasis can issue textual information but is not capable of handling an 
incoming text. Of course, this problem can be solved by declaring a message to be a mail 
message (message types can be identified by a number stored in the message header). 

Inside a mail message, each character can be mapped into an equivalent integer. In this way, 
mail messages can be encoded into numerical form on the sender side, and can be decoded 
back into textual form on the receiver end. However, this technique is kind of crude. We 
suggest that LASP may want to look into this problem. 

Since we have two MicroVAX workstations available, we will be able to actually testbed a 
multiple session environment, and we plan to do so in the case of the remote fluid handling 
experiment. However, this will require Oasis to run on both workstations. For that purpose, 
we may have to buy a larger (159 MByte) disk for the second workstation, an expenditure 
which we had not budgeted for in the first TTPP round. (The second workstation is a tailored 
down workstation with a small disk which may be unable to host the VMS operating system, 
Oasis, and the application databases simultaneously.) 

The problem reported last month with installing the latest release of the OASIS software 
has been resolved. The problem was due to a difference between the versions of VMS 
installed at LASP and the version at the University of Arizona. While LASP had upgraded 
their VMS to release 4.7, the University of Arizona was still running release 4.6. The latest 
release of OASIS will not work with a release of VMS older than 4.7. The problem was 
caused by VMS itself (probably related to the new CCSDS protocols implemented in 
OASIS), and was not caused by the ADA environment, that is, it is not necessary to 
upgrade ADA to its newest release for the newest OASIS release to operate correctly. 

5.2.5 Future Plans 

The initial demonstration projects are on schedule for completion during the next quarter 
(June-September). After that is accomplished, we shall be concerned with writing the final 
report, and with submitting proposals for Phase II of the Telescience Program. It is 
anticipated that this will include further development and enhancement of life science 
applications, as described above, as well as conversion of the Thaw simulator to a realistic 
ATF simulator. A complete list of objectives, requirements, and activities to be simulated 
will be developed as part of this effort. 

5.2.6 TSL Publications 

1. R. A. Bienz and L.C. Schooley, A Survey of Computer Networks, Technical Report 
TSL-001/87, Electrical and Computer Engineering Department, University of Arizona, 
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Tucson AZ, February 1987. 

2. Y. Pan, Teleoperation of Mechanical Manipulators Aboard the U.S. Space Station, 
Technical Report TSL-002/87 , Electrical and Computer Engineering Department, University 
of Arizona, Tucson AZ, December 1987. 

3. L. C. Schooley and F. Cellier, Telescience Testbed Pilot Program Quarterly Report, 
Technical Report TSL-003/87, Electrical and Computer Engineering Department, University 
of Arizona, Tucson AZ, December 1987. 

4- F. Cellier, Teleoperation of the Thaw Telescope at the Allegheny Observatory; A 
Case Study, Technical Report TSL-004/87, Electrical and Computer Engineering 
Department, University of Arizona, Tucson AZ, December 

1987. 

5. L. C. Schooley, R.A. Bienz and F, Cellier, Basic Research in Telescience Testbed 
Program Final Report: NASA Grant NAGW-1Q73, Technical Report TSL-005/88, Electrical 
and Computer Engineering Department, University of Arizona, Tucson AZ, January 1988. 

6. B. Hack, Machine -to- Machine Interface for a Remote Fluid Handling Laboratory, 
Technical Report TSL-006/88, Electrical and Computer Engineering Department, University 
of Arizona, Tucson AZ, March 1988. 

7. L. C. Schooley, D.G. Schultz and F. Cellier, University of Arizona Presentation, 
Second Telescience Testbed Phot Program Meeting, Technical Report TSL-007/88, Boulder 
Colorado, March 7-9, 1988. 

8.. L. C. Schooley and F. E. Cellier, Telescience Testbed Pilot Program Quarterly 
Report for Winter 1987-1988, Technical Report TSL-008/88, Electrical and Computer 
Engineering Department, University of Arizona, Tucson AZ, March 1988. 

9. B. Hack, Man-to-Machine Interface for a Remote Fluid Handling Laboratory, 
Technical Report TSL-009/88, Electrical and Computer Engineering Department, University 
of Arizona, Tucson AZ, April 1988. 

10. B. Hack, Computer Instrument Interface for a Remote Fluid Handling Laboratory, 
Technical Report TSL-0 10/88, Electrical and Computer Engineering Department, University 
of Arizona, Tucson AZ, April 1988. 

1 1 . E. Raize, Computer Interface for Electrophoresis Apparatus, Technical Report, 
TSL-011/88, Electrical and Computer Engineering Department, University of Arizona, 

Tucson AZ, May 1988. 

12. E. Raize, Syringe Driver Assembly for Automated Fluid Handling Laboratory, 
Technical Report, TSL-012/88, Electrical and Computer Engineering Department, University 
of Arizona, Tucson AZ, May 1988. 
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5.3 UNIVERSITY OF CALIFORNIA, BERKELEY 


5.3.1 General 

The majority of the U.C. Berkeley’s telescience effort during this quarter centered around 
preparation for the TTPP II meeting at the Laboratory for Atmospheric and Space Research 
(LASP) of the University of Colorado, in Boulder. Other work involved enhancing our 
network connectivity to the world outside the Space Sciences Laboratory (SSL). We have 
continued to upgrade our software for the remote teleoperation project and the wide area 
software control system (SCS). Lastly, we are preparing three manuscripts to be published 
as conference proceedings of two international meetings. 

Drs. David Gilman and Gunter Riegler of the Astrophysics division, NASA Headquarters 
visited our Laboratory in May. We have briefed them on the progress of our telescience 
efforts and discussed our future plans. 

5.3.2 The Boulder Meeting 

Four members of our team participated in the meeting. Supriya Chakrabarti, Herman 
Marshall and Will Marchant presented status report of our activities. George Kaplan gave a 
brief presentation on IRAF, an image processing and data analysis facility which has seen 
wide applications, particularly in the astronomical community. 

Will Marchant and George Kaplan presented a demonstration of our teleoperation project. It 
consisted of remote commanding of the Extreme Ultraviolet prototype instrument located at 
Berkeley from a workstation at LASP, Boulder, via the Internet. We also collected telemetry 
stream sent by the instrument. The raw telemetry rate was 32 kilobits per second but data 
compression reduced this considerably for the demonstration since only engineering data 
was sent. The science data "slots" were all empty. The demonstrations were conducted 
successfully in spite of numerous periods of network dysfunction. As is usually the case, the 
network would die and then resume function shortly (too shortly!) before a demo. It is 
difficult to estimate the actual network throughput attained, but our guess is that we 
averaged about 4 kilobits per second, with occasional bursts of up to 8 kilobits per second 
between U.C. Berkeley and Boulder. Data compression and encryption issues were also 
addressed in this experiment. 

Furthermore, a visual feedback of the command and telemetry experiment was provided 
through video signals sent over the Internet, which demonstrated the results of command 
executions. Details of the video data handling are described below. 

The intervening time has been spent in attempting to increase our understanding of the 
network environment (and hence, our ability to utilize its scarce resources) and in the work 
of getting evaluation copies of user interface software for us to try. Our efforts in this area 
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are described in a later section. 

Video Support for Demonstrations at the Boulder Meeting 

Our demonstration at the March TTPP meeting in Boulder included visual feedback for our 
remote commanding operations in the form of low frame rate, limited resolution video images 
transmitted over the Internet. Originally, we had not planned to do any work with video but 
we felt the demonstration would be more effective with something more visually appealing to 
display than engineering status readouts. 

In January, we started looking for simple methods of transmitting video images the meeting 
site in Boulder. We selected the Imagewise video digitizing system made by Micromint Inc. 
of Vernon, CT. This system has two components. A digitizer/transmitter grabs individual 
video frames and transmits them over an RS-232 line to a receiver/display unit that converts 
the data back to NTSC format for display on a monitor. Three different resolutions are 
provided, and run-length encoding is used for data compression. Operating at 19.2 Kbps, 
with a resolution of 128 by 122, it is possible to transmit a frame in 10 seconds or less. This 
is sufficient for our demonstration, allowing viewers to see images of the vacuum box door 
before and after the commands have been sent. 

Some additional software was written to allow us to transmit the video images over the 
Internet. The Imagewise transmitter sent video frames to one of the workstations in our lab, 
where a server program performed some additional data compression and transmitted the 
data to a client at the site of the Boulder meeting. The client software displayed each video 
frame in a window on the console screen of the color Sun workstation being used for the 
demonstration. 

Prior to the TTPP meeting we were only able to test the video system on our local Ethernet. 
We were not sure if the Internet would provide enough bandwidth for the demonstration. As 
it turned out, everything worked, in spite of network problems and a last minute change in 
the demonstration hardware in Berkeley. 

5.3.3 NSI Issues 

Those who were able to watch our demo in Boulder know that the performance of the 
network connection from Boulder to Berkeley was, at best, erratic. It was often difficult to 
establish a connection. Once established, the connection would run well for a few minutes 
but then would be lost. Since the TTPP meeting, we have been communicating with Milo 
Medin at Ames and Cliff Frost on the UCB campus about possible causes and solutions to 
the network problems. As a result of this discussion, we have learned a few things about 
NSI (NSN in our case, since we use TCP/IP) which we were unaware of before. Specifically, 
that being connected to NSN does not imply that you can take full advantage of the NSN: 

1. Asa NASA-funded site (and a TTPP participant), SSL is entitled to NSN access. 

2. For technical reasons, only a single NSN connection is made to the LAN at each 
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site. In our case, this is through the BARRNET connection to UCB. 

3. For technical reasons, SSL network traffic cannot be handled differently from the 
general UCB traffic. 

4. As a matter of policy, UCB traffic is not routed via NSN since UCB as a whole is 
not a NASA site. 

This means that although we can use NSN to communicate with a NASA center such as JPL, 
we cannot, in general, use NSN to talk to another TTPP participant, such as the University of 
Colorado. Instead, such traffic is routed via ARPANET or NSFnet, both of which are heavily 
loaded. Some purely technical solutions may be available: 

1. The NSFnet backbone will be converted to T1 this summer. This would have 
helped in our demonstration but it does not address the general problem of NSN access. 

2. We could get an account on a machine at Ames, and log in there in order to access 
the NSN. This is fine for remote logins or file transfers but is not really acceptable for the 
custom client-server software we run for our remote commanding. 

3. It has been suggested that SSL change its network address to be separate from 

the UCB network in order to have our network traffic routed differently. This will also require 
additional communications lines. 

We are presently continuing our efforts toward improving our connectivity to NSI. Until 
recently Marc Siegel at Ames was "99% certain" that the only thing that has to be done is to 
change the routing information on the UCB campus, together with getting a new network 
address for SSL. As of late May, however, the network routing hardware on the UCB 
campus was not capable of supporting separate routing for SSL network traffic. This means 
that we will need to install a separate link to Ames in order to get access to the NSN lines. 
Apparently, NSI will not fund such a link since we are already connected via UCB and 
BARRnet. In coming months, we will be working to resolve the funding and other issues in 
order to get this matter setded. 

Software Control System 

Our existing Software Control System (SCS), allows efficient development of software by a 
group of people. When we developed this system, no commercial product was available. 
Recently, Sun MicroSystems announced such a product, called the Network Software 
Environment (NSE). The EUVE project will be purchasing Sun’s NSE, which performs the 
same functions as SCS but is more flexible and provides better support for multiple revisions 
of a software project. It does not, as far as we can tell, provide direct support for 
collaborations by widely distributed groups. We plan to investigate how the work we have 
completed on an Extended SCS (with nightly updates of directories shared by two sites, 
Berkeley and MIT, for example) can be adapted for distributed sites using NSE. 
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5.3.4 Publications During This Quarter 

We have submitted three abstracts for consideration for reporting in two international 
meetings. Ail three have been chosen for presentations in October and are listed below. 
Supriya Chakrabarti was also invited to chair a session at the 14th annual conference of 
IEEE Industrial Electronic Society (IECON ’88): 


S. Chakrabarti, W. T. Marchant, C. A. Dobson, G. C. Kaplan, M. L. Lampton, and R. 
F. Malina, “Remote Command and Telemetry Handling for a Spaceflight Instrument", to 
appear in the proceedings of IECON’88, 14th Annual Conference of IEEE Industrial 
Electronics Society, Singapore, 1988. 

H.L. Marshall, C.A. Dobson, V. Saba, D. Quinlan, W. T. Marchant, A. Hopkins, G. 
C. Kaplan, R.F. Malina, S. Chakrabarti and S. Bowyer, “The Use of Simulations for 
Developing Hardware and Data Analysis Systems”, to appear in the proceedings of 
IECON’88, 14th Annual Conference of IEEE Industrial Electronics Society, Singapore, 1988. 

S. Chakrabarti, W. T. Marchant, G. C. Kaplan, C. A. Dobson, M. L. Lampton, and R. 
F. Malina, “Telescience at the University of California, Berkeley”, to appear in the 
proceedings of XXXIX International Astronautical Congress, Bangalore, India, 1988. 

5.3.5 Plans for Next Years' Activities 

We have formulated some tentative plans for activities during the next year of TTPP which 
were sent to Dave Koch, Astronomy Leader. The following is a list of some of the activities 
we have discussed: 

Real-time Teleanalysis 

The purpose of this experiment is to exercise and test the teleanalysis capability being 
developed for EUVE. Members of the Space Astrophysics Group at SSL will be launching a 
sounding rocket in September of 1988 to make observations of the Sun and terrestrial 
airgtow. We plan to establish a link from the launch site on Wallops Island, VA to the 
EUVE computer system at SSL in order to obtain telemetry from the rocket instruments in 
real-time. Software adapted from the EUVE End-to-End System will perform a quick-look 
analysis of the rocket data (for example, to determine atmospheric temperature or 
composition). Ideally, results will be produced before the end of the twenty minute data 
window of the rocket flight. 

Teleoperation of EUVE BCE Tests 

This activity will focus on remotely operating the EUVE instruments during planned offsite 
tests using the bench checkout equipment (BCE) computers. Remote operation of the 
EUVE hardware was demonstrated at the March 1988 TTPP meeting in Boulder, CO, using 
prototype command, data, and power (CDP) and telescope interface (TIF) units. By 
establishing high-speed communications channels to the test site in Colorado we will be 
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able to operate the BCE and the instrument from Berkeley. It should be emphasized that 
this is not just a demonstration but will be an essential part of the testing process for the 
EUVE instruments. 

Teleoperation of GSFC Simulator 

We are working with Code 408 at GSFC to perform teleoperations using their EP spacecraft 
simulator. This simulator is also used as the last integration step before the EUVE Science 
payload module is integrated into the real EP spacecraft. During the next year of the TTPP, 
teleoperation with the simulator alone will provide important tests of our ability to operate 
with GSFC prior to the final integration tests and flight operations. 


5.4 UNIVERSITY OF CALIFORNIA , SANTA BARBARA 


We continue to work towards a field experiment in the summer of 1988. The goal of this field 
experiment is to exercise the telescience concept to see what capabilities are truly required 
that are not now available. As we have discussed in previous reports, the field experiment, 
to date, has served very well to focus our attention on both the problems and opportunities 
we face. 

The TTPP-ES splinter meeting on 9 March 1988, in Boulder was extremely helpful. At this 
meeting we reviewed our progress towards our respective goals and discussed our 
respective interests and preparations for the proposed field experiment. We continue to 
work with the rest of the team in this regard. 

One of the experiments we have attempted involves a 9600bps dialup line modem, which we 
have borrowed from Purdue. In the past, we have been unsuccessful in accessing one of 
VAXen through this modem at speeds above 1200bps. After discussions with the 
manufacturer, we finally have been able to provide 9600bps dialup service from our 
BROWSE testbed to the Purdue team. Based on this experience, we have requested that 
the TTPP purchase a pair of Trailblazer-compatible modems for our field experiment. 

Our local science scenarios involve problems of real-time spatial data acquisition and 
modeling. One of the projects involves numerical models of wildland fire behavior. We have 
developed a scenario, based on these models, which may be of value in understanding the 
spread of fire so that the remotely sensed data can provide a useful input to the fire fighting 
crew. We have had discussions with local Forest Service officials and they are working on 
our concept with us. 

As was reported at the TTPP meeting in Boulder, we are working on a data flow exercise, in 
which data residing on a several computers is accessed from a remote terminal (which 
emulates a portable PC in the field), and processing capabilities on several computers is 
used to help solve the problem. We are using a PC/AT with graphics terminal emulation 
software at the user end of the chain, and three VAX computers (involving both the VMS 
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and UNIX operating systems). The network connections tested include both dialup and hard- 
wired access from the PC/AT (1200 and 2400BPS dial, and 9600BPS wired). 

We have run several tests to analyze the performance and reliability of this data transfer and 
processing problem. The general flow of information involves: 

1. requesting data from a database node (UCSB BROWSE Testbed) and transferring 
an image subscene to an image processing system; 

2. (MicroVAX ERDAS)- transferring data to a statistical processing sysrem (S, 
running under UNIX on a VAX 750); and 

3. transferring results back to the PC/AT for further examination by the user. 

The first transfer experiment works, and we are examining several enhancements which: 

1 . include additional processing nodes; 

2. include additional data types; and 

3. exercise a scientific scenario which interests the Forest Service. 

As we become more sophisticated in this effort, we will begin to include our TTPP-ES 
collaborators as sources of data and processing capabilities. 

The second build of the Browse Testbed is now in an alpha-test stage. The principal 
developments in this area include: 

1. a hierarchical vector database structure,; 

2. better use of graphics; 

3. higher effective performance; and 

4. a greater array of image data types. 

In the next qaarter, we anticipate mounting the new software build onto a public account, 
providing a new revision of the user manual to the TTPP-ES team, and encouraging the team 
to use and comment on the testbed. We look forward to similar exchanges with the SME 
database at Colorado and the spectral database af Purdue. 


5.5 UNIVERSITY OF COLORADO, LASP 


5.5.1 OASIS Porting to the SUN Workstation 

The development SUN workstation still has not been delivered. It is now scheduled for 
shipment from the factory on June 9. In the meantime, the VERDIX Ada compiler has been 
installed on a SUN workstation of the CCAR department at C.U. (thanks to Bob Chase), 
and some of the development has been started. 

5.5.2 Operations Management Systems (O MS) / Platform Management 
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System (PMS) Prototype 

The development of the OMS/PMS prototype is progressing well. All coding is complete, 
and we expect to start testing part of the implementation late in June, with a full system 
being operational sometime in August. The completed prototype will provide the tools to 
allow us to address the critical telescience issues of reactive control and transaction 
management. 

5.5.3 Earth System Science 

Remote Access to Data for Teleanalysis 

The primary objective of this task is to establish and exercise a capability which will make it 
possible for others of the consortium to access the LASP SME data, and for us to access 
their databases. The SME MENU system in online and available for use. A preliminary set 
of documents for guiding other consortium users is available, and will be distributed in the 
next few weeks. This material will be reorganized and prepared in the form of an integrated 
final users guide during the coming quarter. 

Preliminary information on the use of the UCSB BROWSE system was received earlier from 
Jeff Star. A first access to that system from Boulder was made during the TTPP workshop in 
March. Thus, we believe that we have the capability to work with that system. 

Arrangements have been made to obtain IBM-PC software for working with the McIDAS 
data received from the University of Wisconsin. That will be put on-line during the next 
quarter, and should give us the ability to acquire and use the NOAA operational satellite 
data. 


Telescience Field Campaign 

Following the discussions described in the last quarterly report to identify a specific set of 
science objectives for the field campaign, the Earth Sciences group met at Boulder on March 
9, 1988. The general research topic settled upon was the role of vegetation in global 
cycles. The long-term objective was to assist in identifying the types of data sets which 
will be needed for broad studies of vegetative coverage in global programs, such as the 
IGBP. The near-term goal was to identify one site and a set of specific tasks which will 
make a substantive beginning in addressing the long-term objective, and which can be 
accomplished this summer as a collaborative effort by the current TTPP Earth Science 
participants within the available resources. 

It was envisioned that some aspects of the four M’s (Measurement, Mapping, Monitoring, 
and Modeling) would be included. There was considerable discussion of potential sites, 
including: 

1 . Oxnard Plain agricultural region (arid but irrigated orchards and truck crops), 

2. Burton Mesa oak woodland, and 
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3. Tippacanoe County cultivated croplands and timber. 

There were initial discussions of the measurements, data sets, models, etc., which would be 
needed. Two alternative approaches were discussed: 

1. The classical measuring and mapping approach, showing how these data feed into 
current models; and 

2. An emphasis on biomass greenness, examining the correlation between greenness 
and what is seen on the ground, and tying these variables to current hydrologic, nitrogen 
cycle, energy, and other models. It was decided to concentrate on the classical measuring 
and mapping approach. 

At the end of the meeting, it was decided that the UCSB and Purdue members would provide 
the primary scientific leadership and content. Colorado/LASP is prepared to provide access 
to the historical data sets and operational support from the SME instruments to obtain new 
data, with emphasis on ozone and other data which may be useful in making atmospheric 
corrections applicable to the other data sets. Colorado (Chase, et al) will be able to provide 
support in use of the HRPT data. Wisconsin is prepared to provide historical 
meteorological data by extracting selected portions of the operational satellite data. These 
would include soundings, cloud cover, rainfall, etc. UCSB is prepared to provide access to 
their library of Land Sat image data and related online databases. 

Identifying the science tasks has proven difficult. The broadly based and integrated 
objective described above would demand a substantial amount of inter-laboratory planning 
and coordination. The problem (and lesson learned) is that it is very difficult for practicing 
scientists to take the time from their current work to plan and execute a new task on short 
notice. In recognition of this problem, we have changed our approach. The collaborators are 
presently defining individual science tasks which are locally oriented. They will, however, 
continue to work toward the general objectives outlined earlier. Cross-linking arrangements 
will be made to give each participant the benefits of easy connectivity, 
which is the hallmark of the telescrence testbed project. 

5.5.4 Astronomy Testbed 

We continued to make steady progress through the last quarter in implementing our 
Astronomy Testbed. The testbed uses an OASIS teleoperations package to provide the 
capability for operating a 16-inch telescope at the Sommers-Bausch Observatory, which is 
located at a remote comer of the University of Colorado campus. This setup is providing a 
convenient, flexible, and scientifically useful testbed for examining the many issues involved 
with remote interactive operations of a Space Science instrument. 

The following tasks have been completed: 

1 . installation of a remote focus control to provide the remote observer with full 
control of the operation; 
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2. installation of a user catalog whereby any approved user can store a private list of 
selected targets for viewing. This is an automated system that saves the catalog from one 
session to another; 

3. installation of search routine. This allows the observer to backtrack to an 
observed feature, and provides a freeze feature that prevents overshots; 

4. The User’s Guide is 10% completed; 

5. installation of software to synchronize the remote and local controlling elements 
and ensure that the remote OASIS controller only sends commands when the local Apple 
Controller is ready; and 

6. A basic testbed environment is complete. This environment includes the telescope; 
two remote sensing instruments/ the local controller; links for voice, data, and video; and, 
the remote OASIS teleoperations package. 

Several Activities Are Planned For The Next Quarter 

1 . The distributed testbed, with its interface to the user-scientist, will be used by 
several science groups and critically evaluated. 

2. The User’s Guide and Help files will be completed. 

3. A capability will be added to allow multiple users to control and/or monitor 
telescope operation simultaneously. Multiple users will be involved in this testbed to 
uncover issues involved with distributed control. 

4. The remote OASIS will be moved into a university classroom to evaluate the 
excitement and educational benefits of telescience. 

5. Many important lessons have been learned in this telescience testbed. These 
lessons are detailed in the enclosed interim report. 

5 . 5.5 Colorado- Ames Testbed 

The Colorado group has been supporting the life sciences testbed at Ames and is looking 
forward to an official start for this activity. 

We are currently awaiting the final version of the Interface Definition Document (IDD) 
controlling the communication interface between OASIS and the other element of the 
testbed. Implementation in OASIS of the support to the communication requirements will 
start as soon as the IDD is formalized. 

5.5.6 MSFC Testbed Support 
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A special V02.03.05 version of OASIS, working with four-color plane 5 VAX II/GPX, has 
been specifically created and installed for demonstration at the Marshall Space Flight 
Center. 

5 . 5.7 Astronomy Testbed 

Lessons Learned and Recommendations Overview 

The Astronomy Testbed at the University of Colorado (CU) uses the OASIS teleoperations 
package and commercial communication services to give us remote, interactive operation of a 
16-inch telescope at the Sommers-Bausch Observatory (located on a remote comer of the 
campus). The testbed provides a convenient, flexible, and scientifically useful environment 
for examining the many issues related to remote, interactive operation of a space science 
payload. 

The testbed was established to allow CU scientists to examine key telescience issues listed 
below. These technical issues have each been investigated in varying levels of detail with 
some expected and some perhaps unanticipated results. These results, including lessons 
learned and preliminary recommendations for space payload operations, are detailed in this 
report. 

The testbed also provided some significant general insights into the advantages of the 
telescience style of operations. According to the users, telescience allowed them to reduce 
or eliminate some of the difficulties involved in using a general observatory (e.g., working 
outside in the cold and in the dark), while preserving the advantages of scientific 
experimentation at the observatory (direct control of operations, experimental and observing 
feedback, and the ability to react to unpredictable conditions). These general advantages 
will likely be the drivers in overcoming any technical challenges to the telescience mode of 
operations. 

The astronomy testbed is made up of the following components: 

1. Telescope; 16-inch F12 Cassegrain telescope by DFM 

2. Photometer Instrument: UBV photo diode photometer by OPTEC-SSP3 

3. CCD Camera Instrument : SONY 

4. On-Site Controller: APPLE II-E 

5. Commercial Phone Links: 1200 baud auto- answer Scholar modems over normal 
commercial phone lines 

6. Video Network: 5 megahertz local area network 

7. Slow Scan Video: Analog video signal at 35 second update 

8. Remote Controller: OASIS (Operations and Science Instrument Support) 
teleoperations package executing on a MicroVAX-II workstation. 

5.5.8 Technical Issues 
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ISSUE 1 : What methods can be used to ensure the safety of on-site crew and the safety of 
the instrument and facility under remote control? 

Approach/Lessons Learned. 

1. Three levels of command pre-checks or interlocks are used: one at the telescope 
itself, one at the onsite controller, and one at the remote controller: 

a. The telescope has absolute limits of operation, and will stop tracking if these 

limits are reached. At that time, control of the telescope is prohibited until a 
manual override is performed. 

b. The on-site controller pre-checks the format of each command upon arrival 
from the remote controller, rejects commands failing the check, and returns the 
reason for the rejection. 

c. The remote controller recognizes certain commands as hazardous and requires 

the operator’s approval before transmission. 

2. The onsite controller checks commands against time-varying limits. If a request is 
made for an out-of-limit command, the on-site controller will not execute the command and 
will return the reason for rejection. 

3. The remote controller has conditional/time-varying pre-checks to verify an 
environment that is safe for the command, thus preventing the telescope from pointing at the 
sun. 


4. Three kinds of limits have been implemented to help the user monitor telemetry: 

a. Absolute: to check if an item is out of its allocated envelope; 

b. Delta: to check if an item has changed by abnormally large amounts; and 

c. Trend: to check if an item will exceed its allocated envelope if the current trend 
continues. 

With these limits, the remote controller can reactively control operations. 

Preliminary Recommendations 

1. Use a combination of both on-site and remote control to assure safety. 

2. Use conditional, dynamic pre-checks or interlocks to guard against potential safety 
violations. 

3. Monitor conditions and trends for reactive control. 

4. Provide the user with control over automatic pre-checks or reactions. 

ISSUE 2: What are the effects of communication delays , and limited sensory information 
on the accomplishment of science objectives? How much feedback is needed to conduct 
experiments with confidence? 
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Approach! Lessons Learned 

1. The use of figures to represent the telemetered orientation of the telescope seems 
to satisfy the needs of an observer to know the orientation of the telescope. 

2. The use of absolute telescope slew moves (based on telemetry), rather than 
relative slew moves (based on time), has eliminated some of the problems of communication 
delays. The user should send one discrete instruction instead of a group of timed 
instructions to accomplish a task. An intelligent local controller would be used to ensure the 
absolute target was reached. With remote control, telemetry should be monitored to ensure 
target acquisition. 

3. When, due to limited bandwidth, there is not enough sensory information to locate 
the exact position of the telescope, onsite acquisition software must be used to establish the 
position of the telescope. Establishing the exact location requires high data rates and low 
data delays, and (with limited bandwidths) can only be accomplished onsite. 

4. When data delays were encountered and more than 30 seconds elapsed before 
acquiring telemetry feedback, the user often became anxious and sent the command 
repeatedly. To avoid this, the automatic procedure should contain a wait statement to 
prevent retries, while allowing the user to override the wait. 

5. When the onsite controller fails to acknowledge commands sent by the remote 
controller, the remote controller will automatically retry the command three times. This 
allows any command to be retried without adverse impact. 

Preliminary Recommendations 

1. Commands should be structured so that they do not depend upon duration of 
transmission, and can be retried as often as necessary without confusion. This can be 
accomplished by the use of single commands that ask the on-site controller to move to a new 
location, or to change rates for a specified amount of time. Commands that ask the controller 
to start an activity that must be then stopped in a timely fashion, create problems for remote 
users. The problem can be solved if the command software is tied to the telemetry, so that 
relative commands can be restructured as absolute commands. 

2. Displays should be structured so that data-driven figures can be defined by the 
user. It is our experience that figures rather than data numbers provide the best view of 
moving components. 

3. There are certain activities which require full bandwidth. Without this kind of 
feedback, these activities must be accomplished on-site. 

ISSUE 3: Can a single user operations interface provide a consistent and effective means 
for controlling a variety of science instruments and platforms? 
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Approach! Lessons Learned 

1. The interface that is used for telescope control can apply to any RA/DEC pointing 
reference system. The need for common figures for such information as field-of-movement 
and graphs of counts versus frequency is widespread through many applications and 
disciplines. 

2. A menu system which allows users to go through a hierarchy at will is useful both 
for the novice using a clear pathway, and the expert without a pre-defined pathway. 

3. Color coding allows the user to recognize dangerous (red) conditions both in color 
and text notation (e.g., ’R’ for a red high limit). One set of color standards should be used in 
all monitoring applications. 

Preliminary Recommendations 

One interface can work for a variety of instruments. This interface would have the following 
features: 

1. the ability to drive figures, cartoons, graphic representations, and icons with 
telemetry data; 

2. the ability to define figures interactively using a combination of standard and user- 
defined objects; 

3. the ability to use menus for instruments and system control instructions; 

4. the ability to set up self-explanatory menus to guide the user through particular 
activities; 

5. the ability to use color to tag out-of-limit items; and 

6. standard colors for standard conditions. 

\SSUE 4: What is the effectiveness of user interface designs for telescience applications? 
Approach/Lessons Learned 

1. Astronomers have been active participants in this project and are eager to design 
the control interfaces, displays and safety controls. 

2. The ability to accept an interface is directly related to the user’s ability to mold 
that interface. 

Preliminary Recommendations 

Provide an interface to the telescience users which they can develop and tailor to their 
needs. 

\SSUE 5 : How do we coordinate instrument control with distributed users competing for a 
shared resource? 
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This issue will be addressed in the continuing testbed investigation. 

ISSUE 6: What operation strategies are useful in situations where scientific observations 
are defined by targets-of-opportunity or specific environmental objectives, rather than 
being limited to block schedules? 

Approach/ Lelso ns Learned 

1. This testbed provides for a user-defined list of observing objects, including the 
planets. This allows the user to define targets interactively, and to locate and track them 
automatically. 

2. This issue will be addressed more fully in the continuing effort. 

Preliminary Recommendations 

1. Any operations system should allow users to store and retrieve information 
specific to their interests and objectives, based on current conditions. 

2. Further recommendations will be made after further examination. 

ISSUE 7: Allocation of control Qfrom total user involvement to total automation. 
Approach/Lessons Learned 

1. There must be one master controller. The local controller has the ability to take 
telescope control at any time and can give that control to the remote controller. The remote 
user can only give up control; he/she cannot send any commands to the telescope until the 
local controller allows it. When control is transferred, messages are transmitted to the new 
controller. 

2. The local controller needs a mechanism to verify that the remote controller is still 
in contact Q as a precaution against communication losses. 

3. This issue will be addressed in a continuing effort. 

Preliminary Recommendations 

1 . Allow duplication of all appropriate functions on both the local and remote 
controllers, to allow easy passage of control between the two. 

2. If the remote user is not able to contact the local controller, then safety should not 
be compromised. 

3. Further recommendations will be made after further activities. 
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ISSUE 8: How can instruments and experimentation methods be designed to take 
advantage of the opportunities of telescience? 

Approach/Lessons Learned 

1. Design instruments to provide video as well as digital indications of pointing. 

2. Problems have been encountered with this application during initialization. The 
telescope was not designed for remote initialization and currently requires some local 
initialization. All operations should be able to be remotely controlled. 

3. The instrument hardware, the telescope, and the experiment should be designed to 
provide full feedback and visibility of hardware and observing conditions to the remote 
observer . 

Preliminary Recommendations 

1 . Design instruments so that the video links can be switched between what the 
instrument is looking at and the instrument; both views are critical. A flexible field-of-view 
is also important. 

2. For many search routines it is more efficient to include the algorithms within the 
onsite controller in order to avoid problems with data links and baud-rate limitations. The 
recommendations on experiment design will be made during the continued activity. 

3. In continuing activities, we will implement experimental programs and sequences 
designed to take advantage of the opportunities of telescience. 

5.5.9 Future Directions 

It has been evident that a ground observatory provides an excellent testbed framework for 
examining the many key issues involved with telescience in the Space Station era. In 
continuing testbed activities we hope to: 

1 . Extend the automated capabilities of the local, onsite controller, in order to 
evaluate autonomous operations and to compare the relative benefits of autonomous versus 
teleoperations. 

2. Extend the testbed framework interfaces to allow multiple users at separate 
physical locations to control the telescope and two instruments, both simultaneously and in a 
time-shared manner. 

3. Apply the existing astronomy testbed framework and tools to a comparison solar 
application. 
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4. Extend the capabilities of the on-site controller to prototype the command 
interlocking and reactive control capabilities of the Operations Management System (OMS). 
This would allow us to investigate the primary telescience issue: "Can we safely operate a 
complex mission while allowing direct, interactive control of the science payload ?” 

5. Augment the testbed to allow examination of teleoperations within a dynamic 
envelope of resources, plus allocation of these resource envelopes. 

6. Continue the testbed investigation to complete the examination of the eight 
original issues listed above. 


5.6 CORNELL UNIVERSITY 


The major finding from tests of currently established networks between Cornell and Arizona, 
and Cornell and Harvard is that these networks are very slow and in many cases unreliable. 
Tests have included file transfer and remote running of applications programs. 

The best solution to this problem would appear to be the construction of specific applications 
programs on either side of the network with only minimal transfer of information over the 
network and good error checking (like OASIS?). This has not been done because it requires 
programming at the basic network level. Even if this is accomplished, the dropout problem 
must be solved if implementation of "near real time" applications are to be possible. 

A summary of network access, activities, test results, and usage is given below: 

1 . Networks used: 

a. Established: ARPA/NSF, BITNET 

b. Regional: NYSERnet 

c. Special purpose! dedicated links: None 

2. Functional use for each of the above: 

a. Email; 

b. Software porting (planned); 

c. Archive/database search (planned); and 

d. Data porting 

3. Utilization of networks: 

a. Daily usage; and 

b. Typical volume: kilobytes (large image transfers not reliable or fast enough) 

4. Performance: 
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a. Reliability: - adequate for email 

- possibly inadequate for large image transfers 

b. Bandwidth: - adequate for email 

- woefully inadequate for large image transfers 

c. Latency: - acceptable for email 

- unacceptable for image transfer and remote software execution 

5. Used for projects outside of TTPP. No other uses yet but likely use in SIRTF and 
reduction of IRAS data under astrophysical data program 

6. Network enhancements needed to do a better job: 

a. higher bandwidth; and 

b. enhanced reliability 

5.7 UNIVERSITY OF MARYLAND 


During this quarter, the primary activity has been to upgrade the hardware for the CCD 
camera system which will be used at Lowell Observatory. The CCD system which is used 
to carry out the telescience was shipped to Maryland at the end of the previous quarter and 
remained at Maryland for the entire quarter while we upgraded the hardware for totally 
remote operation (this upgrade is not funded by TTPP except for the communications 
aspects). It is expected that this upgrade will not be completed until the end of the 
summer. The upgrade includes automation of the filter wheel selection, the grating selection, 
and so on: items which have been varied manually until now. 

We have investigated completion of a network connection to Lowell Observatory but 
because their equipment is in a state of flux, it is not yet possible to define the details 
needed for a SPAN node there. Access to Lowell for electronic mail through the SPAN node 
at USGS has been intermittent, as the USGS node and its connection to JPL have been down 
at different times. This has caused significant disruption of communications, although it has 
not had a direct impact on TTPP since those activities are limited by the upgrade in process 
on the camera. 


5.8 UNIVERSITY OF MICHIGAN 


The REMOTE COACHING system is steadily improving in its capabilities. Personnel in 
the Space Physics Laboratory are using the system on a regular basis, in order to validate 
the operation of the system. On a weekly basis, the expert systems programmer from the 
Robotics Laboratory is meeting with the users in the Space Physics Lab to get a report on its 
operation. Some rules have been found to be incorrect and more video pictures have been 
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needed to make it clearer for the users in the Space Physics Lab. The current version of the 
system is being used for maintenance of an interferometer. However, the final version of the 
system will provide three modes of operation, which are: inquiry mode, maintenance mode 
and diagnostics mode. The inquiry mode is used for by the uninitiated user to learn about the 
operation of the instrumentation used in the experiment. As the operator becomes more 
familiar with the equipment and terminology used, his use of the inquiry mode will diminish. 
In maintenance mode, the user is guided through a sequence of steps for performing some 
maintenance task. In our initial application it is the calibration of the interferometer. If the 
user follows each step exactly, the interferometer will be calibrated at the completion of all of 
the steps. The diagnostics mode is used to determine the cause of a failure in the system. 

In this mode, the user has determined that the system is not working correctly but may not 
know why it is not working correctly. After discovering the cause of the problem, the 
operator can then go into the maintenance mode and the operator is guided through a 
maintenance procedure as described above. 

All three modes provide an option to stop the current operation and establish a 
communication link via modems with the real expert at the local control station (back at the 
university). After establishing the communication link, the COACHING system at the local 
site is brought up to a state of operation identical to that of the remote site. The concept of 
state for the expert system means the activation of the same rule, the same agenda, and the 
same facts. The difficult part in all of this was obtaining the same agenda for each system. 
The rules that are ready to fire are stored in the agenda and the order of their firing is 
dependent upon the order of the facts that were used in there activation. Thus, simply having 
the same rules on the agenda is not enough. The order of the rules on the agenda is also 
important. Our method of accomplishing this was to create another set of rules for storing, 
clearing the fact base, and then reloading the facts. As the facts are reloaded, a new agenda 
is obtained with the same rules as before, but with a reordering of the rules in the agenda. 

By going through this process both agendas at the remote site and at the local site to exactly 
the same state. 

Since the modems have not yet arrived, we have not established communication between the 
remote systems at the Space Physics Laboratory and the local system at the Robotics Lab. 
However, we have temporarily set up a communications testbed within the Robotics Lab 
using a serial line communication between the Sun computer which will be used at the local 
station, and an IBM PC computer, which simulates the portable COMPAQ computer being 
used at the remote site. We are developing the communications software with this testbed 
while waiting for the modems to arrive. The additional work required to use the modems 
instead of serial lines will be minimal. With this testbed system, we have solved the 
problems of capture of a picture at the remote site, compression of the image, transmission to 
the local site, decompression and display on the SUN video monitor. We are now working on 
the software required for creating the dialog between the operator at the remote site and the 
expert at the local site. 


5.9 MIT, ASTRONOMY 
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Networks Used: ARPA/NSF, Athena 

Link to Remote Site: two dialup analog lines, generally used with one modem at 2400 and 
one regular handset; considering an interim upgrade to a Telebit modem that would give up to 
17,000 bits/second. 

Requirements 

A minimum of T1 communications to the site in order to operate in real time for the 
telescience experiments was proposed and accepted. This would allow both images from an 
imaging research photometer and environmental images (weather, maintenance and 
troubleshooting). Use of this link would also extend the daylight hours to use a computer at 
the remote sight for image analysis, etc. 

Functions 

ARPA/NSF: used for email, small data file transfer, electronic bulletin boards, software 
transfer. 

Athena: coexists with the campus ethemet and will be considered in this context as one 
entity. It is used to port software, work with (NFS) network file systems, and basically, has 
become integral to most computer activity. Data acquisition and instrument control currently 
does not take place in realtime over this route. 

T1 communication to remote observatory: This will be used for 

instrument/telescope/observatory control and data acquisition, once it is in place, as well as, 
remote data analysis and recovery of temporarily stored data. 

Time Utilization 

ARPA/NSF: used at least hourly with probably no more than 5 Mbyte average daily volume. 

Athena: used nearly constantly, average volume 10- 100 megabyte per hour during the peak 
use periods. 

Tl communication to remote observatory: planned for nightly use when it is clear for 
observing and computer usage during most other times. Likely volume is multi-megabytes 
per hour. Typically, it would be 30-130 Mbytes per observing run. 

Performance 

ARPA/NSF: marginal performance not good for realtime. Many sites not accessible, though 
in principle they should be. 

Athena: generally good performance, though the bandwidth limits are being approached. 
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T-i communication to remote observatory: not yet in service. 

Use for Projects Outside of Telescience 

ARPA/NSF: All other projects generally become involved in its use. 

Athena: All other projects generally become involved in its use. 

T-l communication to remote observatory : will only be used for Telescience. It is hoped 
that this becomes the preferred mode of operating the observatory. 

Network Enhancement 

ARPA/NSF: Needs about a factor of 100 in speed in order to keep up with current usage. 

Athena: An upgrade to FDDI (fiber) is planned. The dates of implementation have not yet 
been set, 

T-l communication to remote observatory: This is essential to the control and data 
acquisition part of our Telescience program. 

Manned Remote Observing 

This observing is taking place as planned and on schedule. It is to culminate in an observing 
run on the Kuiper Airborne Observatory. Preparation and implementation of this phase is a 
major part of our group effort for the next 2-3 weeks. Additional information is available in 
the last monthly report. 

Optical disc archiving of data across an ethemet is progressing satisfactory. 


5.10 MIT , Life Sciences 


During this quarter, we have seen the " beginning of a coming together" of the various 
pieces of our telescience experiment and procedures. Arrangements were finalized with MIT 
Project Athena to utilize two of their Visual Workstations and two rooms to serve as the PI 
station and the telescience test conductor station. Lines and equipment are being set up. 
Coordination among Athena and Information Services personnel has been an occasional 
problem, which we are working to resolve. 

Rick Fiser, Bob Renshaw and Chuck Oman have been working towards locating and 
procuring a C-band antenna. So far, the major hurdle has been finding a place at MIT which 
will permit permanent installation and still give the appropriate view of the heavens, free 
from microwave interference. To minimize costs, the antenna will be mounted at ground 
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level. KSC has arranged a lease with option to buy arrangement for the antenna to cover all 
possibilities. 

Ilya Shubentsov continued working on the data display portion of the telescience 
workstation. At present, virtually all of the modules are partially written, but they are not 
complete. The main program, the interprocess communications code, the graphing code, and 
the menus are almost complete. 

Braden McGrath continued working on the video control software. Using modified Athena 
software, a live video picture can be placed in one comer of the terminal screen. As an 
added feature, a single frame video picture can be placed in another location. A video menu 
to control the video has been developed. This currently consists of four scroll bar windows. 
The first three scroll bars are used to adjust the frame rate (F), resolution (R), and gray 
scale (G). The fourth scroll window represents the total bandwidth (B = F*R*G) available 
for a given experimental session. 

A preliminary crew training session was held by Oman and Arrott at KSC in May to 
familiarize the surrogate Payload Specialists with the scientific and operational details of the 
experiment. This time was also used to refine the science experiment procedures prepared 
by Modestino and Arrott. The Experiment Payload Specialists picked up on the ideas 
presented quickly. Data lines (19.2 kbaud) are being installed by Contel and the nuances of 
the data format are almost completely defined. 

Weekly teleconferences between MIT, KSC and PSI continued, as did work on the System 
Definition Document. The SDD documents our experiment goals and methodology. 

Dr. Oman, together with Rick Fiser of KSC and Anthony Arrott of PSI, represented MIT at 
the Boulder meeting and participated in a joint presentation on the Life Sciences Testbed, 
which was very well received. Professor Laurence Young, Life Sciences Discipline 
Coordinator, was also present at the Boulder meeting. We made several useful contacts at 
the meeting, which we have since followed up on. A Telescience Life Science Discipline 
group was formed. Among other issues, the group discussed future plans for follow-on life 
sciences telescience activities. The group met again at NASA Ames in early April to draft 
an advisory document. 

5.10.1 KSC Activities 

The Human Use Protocol proposal has been forwarded by BIO-1 to the Human Use 
Committee for review and approval. 

An AVO was drafted to initiate selection of the six Experiment Payload Specialist 
candidates. After they are selected, the EPS candidates are medically certified and are 
currently being trained in telescience operations. 

Manrating of the U.S. Lab Sled was completed on April 26, 1988. 
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Contel ASC is progressing on the installation of the 19.2 Kb data link. The cable was 
installed in the BDCF on April 28, 1988, and a loop test of this circuit was completed on May 
4. Telephone modifications to support voice communication were completed on May 4, 1988. 

The data acquisition and transmission format development with MIT is continuing. Data 
system software development began the second week in May. 

Preliminary KSC inputs to the System Design Document (SDD) have been completed. 

These inputs will be combined with inputs from MIT and PSI. 

KSC inputs to the Life Sciences Telescience Advocacy report have been completed and 
transmitted to Larry Young (MIT/Stanford). These inputs will be combined with similar 
inputs from ARC and JSC to draft a Life Sciences Telescience Advocacy Document, which 
will eventually be submitted to key NASA HQ personnel. 

5.10.2 MIT-PSI Life Sciences 

Besides the ongoing weekly management of the project (Nijhawan), Payload Systems 
(Arrott) also made a presentation at the TTPP meeting in Boulder on the scientific goals of 
the TLSTB and the current status of its development. PSI also attended the meeting with 
Athena Computer Services Personnel to finalize the remaining details for the use of their 
facilities for the testbed. 

The System Definition Document is nearing its first complete draft. We are aiming for 
completion of this draft prior to the test bed scientific operations in early June. 


5.11 PURDUE UNIVERSITY 


5.11.1 Equipment and Software 

The SUN 3/60C was installed during late February and early March. The SUN is connected 
to the Internet with a domain name of newton.ecn.purdue.edu. The 141 megabyte disk drive 
for the SUN broke down within the first two days. A replacement was obtained early in 
March and has worked well since. 

Oracle was installed on the SUN during March. 

Also, the LoDown 800 megabyte WORM optical disk arrived during March from Arc Laser 
Optical Technology (ALOT). Tests of the optical disk have indicated one concern. The 
software that came with the system will only allow one to copy an entire volume (floppy disk 
or disk drive), not just a file or folder, to the optical disk. Therefore, if the file being copied 
does not fill the entire disk that it is on, a lot of space is wasted on the optical disk. ALOT is 
upgrading the software to allow one to copy a file or a folder at a time. They hope to have the 
new version of the software done in early June. 
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5.11.2 Spectrometer/Multiband Radiometer Database 

A prototype of the spectral database catalog has been developed using Apple’s HyperCard. 
Information about the experiments from nine of the thirteen files, including the location, 
researcher, instruments, and scene and/or species have been included in the catalog 
"stacks". The prototype was demonstrated at the Telescience meetings in Boulder, 

Colorado, during early March. The Field Research spectral data base catalog "stacks" are 
available to anyone who would like a copy. 

The eleven files that define the catalog for the spectral data base have been loaded into 
Oracle on the SUN 3/60. The interface for the user is now being implemented. 

5.11.3 University of California Santa Barbara's BROWSE System 

During April, we successfully accessed BROWSE via a 9600 baud dialup using the US 
Robotics modems. The sessions went very well. This has been the most pleasing 
connection to BROWSE from a user point-of-view. The session went much better than any 
connection we have had via the Internet and, of course, better than the slower dialup speeds. 

5.11.4 University of Wisconsin ' s McIDAS System 

During May, we received the latest copy of the McIDAS PC software which requires only a 
color video monitor for accessing and displaying GOES imagery. The system works well on 
our IBM PC/AT system. 

5.11.5 University of Colorado's OASIS 

We have been working with Elaine Hansen and Alain Jouchoux to obtain a copy of OASIS for 
testing remote control of the Solar Mesosphere Explorer satellite. The system that we are 
going to install OASIS on is a VAXstation 2000 which arrived in April. However, some of 
the software is missing for it. As of the end of May, the software still has not arrived from 
DEC. After the software arrives and is tested, we will obtain a copy of OASIS from the 
University of Colorado to install on the VAXstation. From our discussions with Colorado, 
we have determined that OASIS should be relatively easy to port to the VAXstation 2000. 

5.11.6 Earth Sciences Group 

Representatives from the Earth Sciences group met after the Telescience meetings closed in 
Boulder. Representatives were there from University of Colorado, UCSB, Purdue, 

University of Wisconsin and University of Rhode Island. Items discussed included the pilot 
experiment and presentations to the discipline directors at NASA Headquarters. The 
universities were encouraged to discuss individual and collective projects with their 
respective disciplines at NASA Headquarters. 
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A field campaign experiment is being considered for either Indiana or California, as a part of a 
larger ongoing experiment. The universities are currently determining their roles in the 
campaign experiment. 


5.12 UNIVERSITY OF RHODE ISLAND 


As we have mentioned in previous communications, our general goals in the TTPP project 
are to investigate and develop ways of providing efficient remote access to digital image 
archives, i.e., to develop image browse software for accessing image archives. As of the end 
of this reporting period, we have two essentially complete implementations of the software: 
one for use at DSP sites on the SPAN network, and one for use on an IBM PS/II using a 
dialup connection to our archive. In this report, we will describe an important detail of our 
approach, mention major events during the quarter, and indicate our plans for the next 
several months. 

Again as we have mentioned, part of our general approach to the remote access problem is to 
construct an image pyramid for a given image, each level of which is a reduced resolution 
representation of the original and to send successive levels of the pyramid, starting with the 
lowest resolution level, until the user stops the process either to abort or to ask for an just 
an inset area at higher resolution. A fundamental parameter in this is the function by which 
the pyramid is generated from the original image. Various functions are possible and have 
been used for a variety of applications, e g., means, median values, etc. We think it is worth 
noting that for our AVHRR application, in which the basic objective is to allow a viewer to 
decide whether an image contains useful data and to determine its type in « one minute 
(and likely for a variety of other remotely sensed image data, as well), a simple sampling 
function is adequate. A sampling procedure, rather than some more complex function, means 
that there is minimal computational overhead, that the entire image does not need to be in 
memory before transmission can begin, and that there is no redundancy (or computational 
overhead in avoiding it) in sending an image. Sending a complete nxn byte image requires 
only n x n bytes. We were surprised that such a simple scheme works so well. Maybe there 
is a lesson in this. As far as significant events or activities during the quarter, we would like 
to mention four. First was our demonstration of our basic PS/II implementation in Boulder in 
March. This showed that even at 1200 bps, it was possible to browse a remote archive and 
meet or nearly meet the objective mentioned above. Second, though we did not attend the 
Image Compression Conference in Utah, we have consulted with a local expert, Peter 
Swazek in our EE Dept., who has helped us identify a combination of several 
computationally cheap techniques which can be easily added to our approach. We may be 
able to achieve >40% loss less compression with them. Third, during the Second New 
England/Canadian Ocean Technology Exchange Conference held here at URI recently, we 
demonstrated our system to representatives of the Bedford Institute of Oceanography of 
Nova Scotia. They are putting together an AVHRR archive and have expressed strong 
interest in adapting/adopting our system. Lastly, one of our students has begun to 
implement "intelligent interface" functionality into our browser. The basic idea is to use a 
machine learning classifier algorithm to learn the characteristics of the desired images from 


- 50 - 



TTPP Fourth Quarterly Report (M88.4) 


June 1, 1988 


the first "few" browsed. 

Our plans for the next several months have three foci. We intend to release our software 
more widely, to more DSP-SPAN sites, in order to gain additional user experience. We will 
implement and experiment with various compression schemes. Finally, we will push hard on 
the intelligent interface implementation. Our goal here is a prototype by September 1988. 


5.13 RENNSELAER POLYTECHNIC INSTITUTE 


The activities of the RPI/LeRC team during this period involved both software and hardware 
development. In the area of hardware development at RPI, we have identified the science 
experiment to be used in the first trial of the telescience testbed. It consists of a nucleation 
study of fluoride glass at temperatures just below the melting point. This will be done by 
observing a small glass sample under indirect lighting which enhances the viewing of the 
nucleation sites within the sample by quadrature light scattering. The creation and growth 
of the crystals as a function of temperature will be observed and recorded. A small oven has 
been modified to accept the light source and the controller has been interfaced to an AT. This 
experiment will be done in three phases: 

1. manually operated; 

2. remotely operated at RPI; and 

3. remotely operated at LeRC 

The type of video to be used, i.e., analog or digital, will also be varied. Software 
development was the main effort during this period, as we finally received the complete Sun 
system. The desired format follows. 

5.13.1 On the Sun--(Control Site) 

A three process, three window, program will be running on the Sun. Process #1 will 
periodically request a new video picture from the remote site and display it in window #1. 
Process #2 will periodically request an update of analog information from the site and display 
the latest update along with the previous nine updates in window #2. Process #3 will accept 
keyboard requests for command transmission, format the command and transmit it. The 
latest command will be displayed, as well as the previous nine in window #3. 

5.13.2 Transmission 

The Sun will communicate with the remote site via a 9.6kb dialup modem. The above three 
processes will time share this facility. 


5.13.3 On the AT Clone--(remote site) 
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At the remote site the 9.6kb modem will communicate via RS-232 with an AT clone. The 
clone will control the experimental equipment and also contain a frame grabber for video 
digitalization. On appropriate command from the control site, the clone will execute the 
desired action and transfer the requested data to the control site. 

Efforts at both RPI and LeRC during this period have been focused on creating the various 
subroutines for the Sun (UNTX/OS), the AT clone (MS-DOS/OS) and the communication 
link. Although OASIS was considered, it could not be used at this time since it was not 
ported to a UNIX system and did not handle video files. The following major requirements 
were accomplished and tested during this period: 

1. display of digital video pictures from the AT frame grabber on the Sun-RPI 

2. operation of the frame grabber on the AT-LeRC 

3. control of an oven controller by the AT-RPI 

4. control of an oven controller by the Sun through the AT-RPI 

5. control of stepper motors by the AT-LeRC 

Creation of other required processes and the integration into one program (3?) on the Sun 
and one on the AT remains a difficult but high priority effort. 

5.13.4 Plans for the Next Quarter 

During the fifth and final quarter, we hope to complete the following: 

1. installation of a teleconferencing net between LeRC and RPI.(Lack of equipment 
prevented completion as planned this quarter); 

2. full scale inhouse glass experiments at RPI; 

3. initial remote experiments at LeRC. 

5.14 SMITHSONIAN ASTROPHYSICAL OBSERVATORY 


5.14.1 Programmatic Statuses 

During the fourth quarter, March through May 1988, a number of major programmatic 
activities were carried out. At the TTPP II meeting in Boulder, March 7-9, a presentation of 
the activities at SAO was made. A splinter meeting of the astronomy Pis was also held. 

The following topics were discussed at the splinter meeting: use of OASIS, data 
compression, network transmission and interoperability of catalogs. 

The TTPP astronomy Pis were polled with regard to preliminary results from their TTPP 
activities. This data was to provide background information for use at NASA Headquarters 
in compiling some early information on the results of the TTPP activities. Secondly, the 
TTPP astronomy Pis were polled on their experiences so far in use of the networks. This 
information was digested and is provided as the astronomy discipline input for this quarterly 
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A no-cost extension to the S AO subcontract for TTPP was granted through 3 1 October. 

Since no further funds were provided, the present activities will be spread out over the 
extension time period. 

5.14.2 Technical Statuses 

The major technical advancement in the last quarter is the completion of the microwave link 
between Tucson and the Ridge on top of Mt. Hopkins. This forms a LAN for the SAO 
MicroVAXes in Arizona with two in Tucson, one at Steward Observatory and one on Mt. 
Hopkins. One of the machines in Tucson, agilely, is a class B node and serves as a gateway 
to the University of Arizona campus. The LAN also has the VAX gamma in Tucson and the 
VAX, Anile, on Mt. Hopkins connected by the microwave (Tl) link. We can now login on 
agilely via the Internet from Cambridge and then login on anile. Unfortunately, the University 
of Arizona has not yet been able to broadcast the routing for Annie, so that we can log in 
directly. This is being looked into. 

The main purpose for the microwave link was to provide for a network connection to the 
MicroVAX anile which will be used for data acquisition from the new IR camera. This 
camera is nearing the end of development and it is hoped that it can be used at the telescope 
for the first time at the end of June. In preparation for this, SAO has been developing data 
acquisition software for arrays to be run on MicroVAX GPX under Ultrix. This software is 
nearing completion and is ready for mntime testing. A demo of the software was run in 
Tucson for the University of Arizona’s Steward Observatory. The binary of the software 
was downloaded over the Internet to Tucson (about 0.5 MB binary file). We have also 
installed IRAF on anile. This was accomplished remotely from Tucson over the microwave 
link. 

Recently, our experience with the Internet connection to Tucson has been poor. For the last 
half of May, we were unable to connect to Tucson. This is being looked into further. We are 
eagerly waiting for the NSN connection to be made at Tucson. 

5.14.3 Activities Planned for the Next Quarter: 

We are anticipating running the IR camera at the telescope in June. To accomplish this will 
require substantial support from Cambridge by our software personnel. We anticipate a 
period of activity during the next month, when the data acquisition will be remotely 
installed, debugged, and upgraded, as the IR array is brought into an operational mode. The 
network connections will be the key to this activity. 


5.15 STANFORD UNIVERSITY 


The Stanford effort of the Telescience Testbed Pilot Program is directed towards the 
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development of multimedia telescience workstations for a variety of real-time instrument 
control and monitoring functions. The two types of computer workstations being used are 
DEC VAXstation H workstations running under the VMS operating system and Sun 3 
workstations running under the UNIX operating system. In order to support real-time data 
display and instrument commanding, the University of Colorado OASIS software package 
has been installed on the VAXstation and the NASA Transportable Applications Executive 
(TAE) is being planned for installation on the Sun workstation. The VAXstation/OASIS 
interface is planned to be implemented for a simulation of the Spacelab-2 mission, to 
determine the requirements for realtime data transmission in space operations. One goad of 
the Spacelab-2 simulation is to capture the transmitted data and distribute the data to 
computer workstations on a local area network. The Sun/TAE interface is planned to connect 
to the Space Station Testbed Facilities at Johnson Space Center to evaluate the interfaces 
and resources being planned for science experimenters. The initial project involves 
duplicating the data display and command system which ties into the payload simulator in 
the Space Station Testbed. Another joint effort with the group at the University of California 
at Berkeley has been to explore remote operations of EUVE prototype hardware from the 
Stanford STAR Laboratory. The Telescience Testbed activities also compliment joint 
activities between Stanford University and Goddard Space Flight Center, Johnson Space 
Center, and Kennedy Space Center. 

The shared computer facilities at the Stanford STAR laboratory have been undergoing a 
major change in the last several months. The cluster of VAX 1 l/780s and 1 l/750s have been 
replaced by MicroVAX based file servers and dependent Micro VAX compute servers and 
VAXstation workstations. Two independent file servers have been set up; one under the 
VMS operating system and supporting dependent workstations under a Local Area VAX 
cluster, and the other under the Ultrix (VAX UNIX) operating system and supporting 
dependent workstations by the Network File System (NFS). The STAR laboratory 
computer system is designed to provide basic computing support to the laboratory, and to 
more fully support a workstation environment by providing operating system maintenance 
and access to peripherals, such as printers for workstations throughout the laboratory. Both 
the VMS and Ultrix MicroVAX systems are connected to the ARPAnet (including the Nasa 
Science Internet and NSFnet) and the NASA Space Physics Analysis Network (SPAN). 

Negotiations with Sun Microsystems have resulted in orders being placed for a Sun 3/260 
workstation for the Stanford STAR Laboratory aspects of the Telescience Testbed Pilot 
Program and a Sun 3/60 workstation to be placed at NASA Headquarters. The STAR 
Laboratory Sun 3/260 workstation has been received and setup, and Version 3.5 of the Sun 
Unix operating system has been installed. Portions of the TeleWEn (Telescience 
Workstation Environment) have been installed from the database at RIACS, and additional 
subsets of the TeleWEn library will be obtained as the library contents are reviewed. The 
delivery of the Sun 3/60 workstation for NASA Headquarters has been delayed as a result of 
the current memory chip shortage. 

The Transportable Applications Executive (TAE) software package is being explored as a 
means of using computer workstations for spacecraft instrument monitoring and control. A 
demonstration instrument interface based on TAE has been received from Goddard Space 
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Flight Center and was brought up on the Sun 3/260 workstation. This demonstration program 
is based on the High Resolution Solar Observatory proposed for future Spacelab flights, and 
provides a simulation of controlling the operation of optical instruments viewing solar 
features. The demonstration program has been successfully installed and tested. It is 
planned to interface the program to a payload simulator running on another computer in order 
to provide a more realistic simulation of instrument commanding. In the near future, it is 
intended to interface the TAE workstation with a computer running an identical payload 
simulator at Johnson Space Center. In addition, the complete TAE+ package has been 
requested and will be installed on a Sun 3/260 workstation. The intent it to begin to develop 
command and data display interfaces for instruments that have flown on Spacelab-2 and are 
being developed for the Shuttle Electrodynamic Tether. 

A similar effort is involved in the evaluation of the University of Colorado OASIS package to 
determine how it can be interfaced to display science and engineering parameters in a 
particular application. Another goal is to develop appropriate connections to a payload 
simulator for commanding purposes. The Oasis software has been installed at Stanford 
University on a GPX VAXstation running the VMS operating system. The examples and 
interface definitions are being studied in order to understand how to customize the input and 
displays for specific uses such as the simulation of the Spacelab-2 mission. 

One aspect of the efforts for a simulation of the Spacelab-2 mission is the development of a 
workstation based display of the Shuttle Orbiter to indicate both predicted and realtime 
parameters important to the experiments being conducted. The display shows the electron 
trajectory emitted by a low power electron source and vectors indicating the direction to the 
sun and the center of the earth, the earth’s magnetic field direction, and the direction of 
motion of the Orbiter. The code which provides this display on a Silicon Graphics IRIS 
workstation has been modified to access display parameters from another computer across 
an ethemet interface. The modified code has been tested by accessing display parameters 
from remote workstations running under both the UNIX and VMS operating systems, 
through a standard ethemet interface. Several interesting problems developed in the course 
of the communications program development. The first is that the floating point 
representations under the VAX architecture are different than those used on the Silicon 
Graphics and Sun workstations, which use the IEEE floating point standard. The difference 
could be easily solved by converting the numbers at the source workstation, but it 
complicates the development of a portable code for standard communications. The second 
problem concerns the way spawned processes interact under the UNIX operating system 
versus the VMS operating system. A spawned process under UNIX can conrmunicate with 
the parent process via a mode called a non-blocking read in which a spawned process 
waiting for external input will not force the parent process to also wait for the input. The non- 
blocking read is not currently possible under VMS, so that other solutions to the 
communications handshaking needed to be developed. Evaluation of the code is underway to 
determine if there is a program structure that can minimize the differences in the code in 
order to make the code more portable. 

A cooperative rapid-prototyping project has been underway with Kennedy Space Center to 
develop a computer interface for shuttle tile inspection. The first part of the project has 
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developed a voice entry and verification system to input tile step and gap measurements 
directly into a relational database. The voice system consists of a voice recognition unit and 
a speech synthesis unit which are connected to an ethemet based terminal server by 
standard terminal lines. The voice recognition unit converts human voice into digital 
characters and relays the information to a computer workstation which enters the values into 
a database. Input verification is achieved by echoing the input data back to the user through 
the speech synthesis unit. A system is being implemented at Stanford STAR Laboratory 
which will be identical to the system being used at Kennedy Space Center for tile automation 
project. A voice recognition unit and a speech synthesis unit have been received by and a 
ethemet based terminal server is on order. The intent is to use the voice system as a 
portion of a multimedia telescience workstation. 

Discussions have been held with personnel from Stanford University, SRI International and 
RIACS about developing the Sondrestrom Incoherent Radar Facility in Greenland as a 
remote Telescience Testbed project. The Sondrestrom facility is currently funded by the 
National Science Foundation to study atmospheric and ionospheric phenomenon at high 
geomagnetic latitudes. The current mode of operation requires visits by outside science 
users to perform their research, particularly for study of phenomenon requiring real-time 
interaction. The remote location of the facility, realtime data requirements, and moderate 
initial data rates suggest the Sondrestrom facility as an appropriate model for a remote 
Telescience research site. The facility computer and communications networks are being 
evaluated, and possible upgrade options are being developed to be explored for continuation 
of the Stanford Telescience projects. 


5.16 UNIVERSITY OF WISCONSIN 


Telescience efforts at the University of Wisconsin have resulted in advances in two main 
areas during the past three months: 

1 . improvements of IBM PC software designed for the reception and display of 
Me ID AS data products; and 

2. establishment of a connection to the USAN (NSFnet) ethemet in our building. 

5.16.1 IBM PC Software and the McIDAS Database 

We have modified our version of IBM PC software so that only a color video monitor is 
necessary for accessing and displaying GOES visible, IR, and water vapor imagery. The 
older version only worked with both monochrome and color displays operating 
simultaneously. The software runs on an IBM PS/2 or an AT equipped with an EGA and 
enhanced color display. The package uses a Telebit modem and standard asyncronous dialup 
to access the McIDAS database. It is also compatible with a Hayes 1200 or 2400 Baud 
modem but the data transfer rate is greatly reduced from the 18K baud that is possible with 
the Telebit modem. The software also includes a scheduling option to allow automatic access 
of a time sequence of images useful for cloud animation. 
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The software is available upon request to TTPP participants. Lindsay Feuling, who can be 
reached at (608) 263-4494, is largely responsible for this update and will be responsible for 
distributing the software and helping you get started. 

Copies of the software have been distributed to Purdue, UCSB, and to the University of 
Colorado-LASP. We are awaiting feedback from these users. 

Please bear in mind that this software displays only a small subset of the real time data 
products that are accessible in the McIDAS database. A recent addition is AVHRR data via 
our DOMSAT link. If you have questions about the list of products available, feel free to 
contact us. 

Connection to the USAN ( NSFnet ) TCP/IP Network 

We have recently made a connection in our building to the USAN ethemet (NSFnet), using 
an IBM AT which will be the foundation of a McIDAS bridge. Our new host name is 
"McIDAS.ssec.msc.edu" and is at IP address 128.1 16.12.97. An anticipated change in our 
campus configuration may require a change of address. Our host name is known to our 
campus gateway (STEER at 128.1 16. 12.1). We have tested this connection using a 
commercial software package purchased from FTP Software, Inc. Results of the testing 
have verified the integrity of the hardware. We have been able to establish contact with a 
number of foreign hosts for the purpose of FTP operations. Testing of email operations using 
the USAN connection have revealed that a number of reliability problems still exist. We 
suspect that the problem lies in the mail relay host we are utilizing. We are continuing to 
work the problem My alternate email addresses are: 

RGDEDECKER@MCIDAS.SSEC.WISC.EDU ; 
RGDEDECKER@VMS.MACC.WISC.EDU (ARPANET); and 
RGDEDECKER@WISCMACC (BITNET) 

The software package purchased from FTP Software, Inc. includes a development package 
which supports the TCP/IP and FTP. We are beginning efforts to develop software to 
establish a bridge between McIDAS and the NSFnet. We discovered a problem that 
required us to utilize an upgraded development package. We recently received the software 
update from FTP Software, Inc and have resumed testing. Until we complete the bridge 
software, a path for providing McIDAS data products exists but requires manual operator 
intervention. 
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AAS 

(American Astronomical Society) 

AGC 

(Automatic Gain Control) 

AIPS 

(Astronomical Image Processing System) 

ALOT 

(Arc Laser Optical Technology) 

Andrew 

(Multimedia mail system with capabilities similar to Diamond; basis of 
Camegie-Mellon EXPRES system) 

ARC 

(Ames Research Center) 

ARPA 

(Defense Department Advanced Research Projects Agency) 

ARPANET 

(Wide area data network supported by ARPA) 

AT 

(Astrometric Telescope) 

ATF 

(Astrometric Telescope Facility) 

AVHRR 

(Advanced Very High Resolution Radiometer; on the nimbus series of 
satellites. Run through NOAA) 

B&W 

(Black and White Display) 

BARRNET 

(Bay Area Regional Research Network) 

BAUD 

(not an acronym; a unit of signaling speed; refers to the number of 
times the state or condition of the line changes per second) 

BCE 

(Bench Checkout Equipment) 

bps 

(bits per second) 

CAS 

(Canadian Astronomical Society) 

CCD 

(Charge Couple Device; a technology for converting images into 
electrical signals) 

CCSDS 

(Consultative Committee for Space Data Systems) 

CDP 

(Command, Data, and Power interface unit; part of the EUVE 
instrument) 

CLIPS 

(A programming language for expert systems. A copy of the source 
program (written in C) was sent to U of Michigan from Johnson Space 
Center, Mission Support Directorate, Mission Planning andAnalysis 


Division. It is in the public domain and has been installed on several 
systems, (IBM PC -Microsoft C, Sun, Dec.)The only restrictions to 
its use is that you can not sell it.) 

CODEC 

(Co-der/Dec-oder) 

CSDF 

(Commercial Space Development Facility) 

CUI 

(Common User Interface) 

DEC 

(Digital Equipment Company) 

DMIL 

^Direct Manipulation Interface Language) 

DSP 

(Digital Signal Processing) 

EPS 

(Experiment Payload Specialist) 

EUV 

(Etreme Ultraviolet) 

EUVE 

(Extreme Ultraviolet Explorer) 

EXPRES 

(Experimental Research in Electronic Submission) 

FUV 

(Far Ultraviolet) 

FRICC 

(Federal Research Internet Coordination Committee) 

GETSCI 

* 
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GOES 

GPX 

GSFC 

HCIG 

HIPS 

HRPT 

HUP 

IAPPP 

IBM 

IDL 

IGBF 

IGBP 

IL 

IMS 

Ingres 

IOMS 

IPAC 

I R AF 

IRAS 

JPL 

JSC 

JVNCC 

KSC 

KSCBCF 

Kermit 

Kiwi 


LAN 

LASP 

LCC 

LIB $TP ARSE 

LSTB 

Magic/L 

McIDAS 

MIT 

MMSL 

MMT 

MSFC 

NASA 

NASA SELECT 

NASCOM 

NICOLAS 

NOAA 

NOAA-G 


(Geostationary Operational Environmental Satellite) 

(Graphics Processor WorkstationforMicroVAX II) 

(Goddard Space Flight Center) 

(Human-Computer Interface Guide) 

(Human Information Processing Laboratory’s Image Processing) 

(High Resolution Picture Transmission) 

(Human Use Protocols) 

* 

(International Business Machines) 

(Interactive Data Language) 

* 

(International Geosphere Biosphere Program) 

(Intermediate Language) 

(Instrument Management Services) 

(Database) 

(Instrument OMS) 

(Infrared Processing and Analysis Center at Caltech) 

(Image Reduction and Analysis Facility) 

(Infrared Astronomy Satellite) 

(Jet Propulsion Laboratory) 

(Johnson Space Center) 

(John Van Neuman Computing Center) 

(Kennedy Space Center) 

* 

(File Transfer Program) 

(not an acronym; a "flightless bird" consisting of prototype EUVE 
electronics) 

(Local Area Network) 

(Laboratory for Atmospheric and Space Physics) 

(Local Controlling Computer) 

(VAX/VMS library routine that provides a table driven parser. Used for 
the initial version of the CSTOL parser for OASIS) 

(Life Sciences Testbed) 

(interactive programming language developed by Loki Engineering, Inc.) 
(Man Computer Interactive Data Access System) 

(Massachusetts Institute of Technology) 

(Microgravity Materials Science Laboratory) 

(Multiple Mirror Telescope on Mt. Hopkins, AZ) 

(Marshall Space Flight Center) 

(National Aeronautics & Space Administration) 

(NASA run TV channel which carries NASA related events) 

(NASA Communications- mission critical) 

(the inter-network gateway at Goddard Space Flight Center) 

(National Oceanic and Atmospheric Administration) 

(Name of the NOAA polar orbiting satellites) 
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NRAO 

NSE 

NSF 

NSFnet 

NSI 

NSN 

NTSC 

OASIS 

OMS 

OMS/PMS 

OMSS 

OSSA 

PI 

PSI 

Project 

RA 

RCC 

RFH 

RGB 

RIACS 

ROM 

RS-232 

SAIS 

SAO 

SCS 

SIMBAD 


SME 

SOP 

SPAN 

SPIE 

SS 

SSE 

SSIS 

SSL 

SSP 

STScI 

TAE 

TATS 

TCP/IP 

TDRSS 

TeleWEn 

Terracom 


(National Radio Astronomy Observatory) 

(Network Software Environment) 

(National Science Foundation) 

(Data network supported by NSF) 

(NASA Science Internet) 

(NASA Science Network; TCP/IP part of NSI) 

(Standard video signal format) 

(Operations and Science Instrument Support) 

(Space Station Operation Management System) 

(Operations Management/Platform Management) 

(Operation Management Services) 

(Office of Space Applications & Applications) 

(Principal Investigator) 

(Payload Systems, Inc.) 

(MIT student network) 

(Research Assistant) 

(Remote Commanding Computer) 

(Remote Fluid Handling) 

(Red, Green, Blue Video Display) 

(Research Institute for Advanced Computer Science) 

(Read Only Memory) 

(Standard for serial data transmission) 

(Science and Applications Information Systems) 

(Smithsonian Astrophysical Observatory) 

(Software Control System) 

(Primarily a bibliographical cross reference database of 700,000 stellar 
and 100,000 non-stellar objects, which can be logged into remotely 
from around theworld; set of identifications, measurements and 
bibliography for astronomical data) 

(Solar Mesosphere Explorer satellite) 

(Science Operations Subgroup) 

(Space Physics Analysis Network) 

(Society of Photo-Instrumentation Engineers) 

(Space Station) 

(Software Support Environment) 

(Space Station Information Systems) 

(Space Sciences Laboratory at UC, Berkeley) 

(Space Station Program) 

(Space Telescope Science Institute) 

(Transportable Applications Executive) 

(Thaw Atmospheric Telescope Simulation) 

(Transmission Control Protocol/Intemet Protocol) 

(Tracking and Data Relay Satellite System) 

(Telescience Workstation Environment) 

(a company name) 
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TFSUSS 

(Task Force on Scientific Uses of Space Station) 

TIF 

(Telescope Interface Unit) 

TIGS 

(Testbed at LASP) 

TMIS 

(Technical Management Information System) 

TTPP 

(If you don’t know this by now it’s too late!) 

UC 

(University of California) 

UCB 

(University of California, Berkeley) 

UCSB 

(University of California, Santa Barbara) 

UIL 

(User Interface Language) 

Unify 

(Database) 

UofA 

(University of Arizona) 

USE 

(User Support Environment) 

USRA 

(Universities Space Research Association) 

UW 

(University of Wisconsin) 

VISTA 

(another image processing system) 

WAN 

(Wide Area Network) 
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of telescience. 
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Chakrabarti, Supriya, Carl A. Dobson, George C. Kaplan, Herman L. Marshall, Michael Lampton, Roger F. 
Malina, Stuart Bowyer, and Jeff Star, "Astronomical Data Analysis from Remote Sites," 

Astronomy from Large Databases , Scientific Objectives and Methodological Approaches , EOS 
Conference and Workshop Proceedings, vol. 28, p. 295, Space Sciences Laboratory, UC Berkeley & 
Remote Sensing Research Unit, UC Santa Barbara (J. Star), Berkeley, CA, January 1988. Also 
available in Space Astrophysics Group Contribution Number 329. 

Given the progress in the communication technology, it is expected that during the space station era the 
mode of instrument operation and data analysis will be dramatically different. A consortium of 
several universities and NASA centers are evaluating various aspects of design and operation of 
scientific instruments and data analysis over various computer networks from a remote site. Such a 
scheme has officially been termed telescience. We will report on the development of methodologies 
for teledesign, teleoperation and teleanalysis and the verification of these concepts using the Extreme 
Ultraviolet Explorer (EUVE), a satellite payload scheduled for launch in 1991. The EUVE telescopes 
will be operated remotely from the EUVE Science Operation Center (SOC) located at the University 
of California, Berkeley. Guest observers will remotely access the EUVE spectrometer data base 
located at the SOC. Distributed data processing is an integral part telescience. We will describe our 
experience with the Browse system, currently being developed at the University of California at Santa 
Barbara through a grant from NASA for remote sensing applications. We will discuss the suitability 
for its adoption for astronomy applications. Browse allows the examination of a subset of the data to 
determine if the data set merits further investigation. The examination can be as simple as looking for 
a specific data element based on its location, date of observation, quality indicator, spectral coverage 
etc. It also allows the viewing of data in various modes depending upon the available resources at the 
user’s end (e g., graphics terminal vs. dumb terminal), level of data compression applied, required 
display format etc. and its transmission over a network to a local graphics display station. 

Gallagher, Maria L., Telescience Testbed Kickoff Meeting Minutes , RIACS TR 87.25, 26 pp., 

RIACS/USRA, Moffett Field, CA, September 1987. 

The kickoff meeting for the Telescience Testbed Pilot Program was held on July 30-31, 1987 at NASA 
Ames Research Center. These are the minutes of that meeting. 

Gallagher, Maria L., Telescience Testbed Pilot Program Meeting 11 Minutes , RIACS M88.1, RIACS/USRA, 
Moffett Field, CA, March 1988. 

The TTPP II meeting was held on March 7-9, 1988 in Boulder, Colorado. These are the minutes of that 
meeting 

Gallagher, Maria L. and Barry M. Leiner, Telescience Testbed Pilot Program First Quarterly Report , RIACS 
TR 87.26, 35 pp., RIACS/USRA, Moffett Field, CA, September 1987. 

The Telescience Testbed Pilot Program participants are required to issue reports to NASA 
Headquarters on a quarterly basis. This is the first quarterly report, covering the period April 28, 
1987 through August 31, 1987. 

Gallagher, Maria L. and Barry M. Leiner, Telescience Testbed Pilot Program Second Quarterly Report , 
RIACS TR 87.31, 57 pp., RIACS/USRA, Moffett Field, CA, December 1987. 

The Telescience Testbed Pilot Program is an innovative activity involving fifteen universities in user- 
oriented rapid-prototyping testbeds to develop the requirements and technologies appropriate to the 
information system of the Space Station era. The Telescience Testbed Pilot Program is required to 
issue progress reports to NASA Headquarters on a quarterly basis. This is the second quarterly 
report, covering the period September 1, 1987 through November 30, 1987. 
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Gallagher, Maria L. and Barry M. Leiner, Telescience Testbed Pilot Program Third Quarterly Report , RIACS 
TR 88.8, 77 pp., RIACS/USRA, Moffett Field, CA, March 1988. 

The Telescience Testbed Pilot Program is required to issue progress reports to NASA Headquarters on a 
quarterly basis. This is the third quarterly report, covering the period December 1, 1987 through 
February 29, 1988. 

Hack, B., Man to Machine , Machine to Machine and Machine to Instrument Interfaces for Teleoperation of 
a Fluid Handling Laboratory , Technical Report TSL-0 14/88, Electrical and Computer Engineering 
Department, University of Arizona, Tucson, A Z, June 1988. 

The purpose of this thesis is the design and description of the software necessary for teleoperation of a 
remotely operated fluid handling laboratory. It does not include the implementation of this software. 
The laboratory for which it is designed is currently being developed at the University of Arizona, and 
is intended to be a small scale model of the fluid handling laboratory which will be aboard Space 
Station. The designed software includes a man/machine interface, a machine/machine interface, and a 
machine/instrument interface. The man/machine interface is graphical in nature, menu driven, and 
consists of high level commands which are independent of the devices in the laboratory. The 
machine/machine interface is also device independent. It consists if intermediary commands and maps 
the commands of the man/machine interface to low level, device dependent, commands and programs of 
the machine/instrument interface. Although the software is primarily designed for the model fluid 
handling laboratory, the needs and requirements of the operation of a similar laboratory aboard Space 
Station have been considered. 

Kaplan, George C., “EUVE Contributions to Telescience/ ’ EUVE Technical Bulletin , no. 4, p. 2, Space 
Sciences Laboratory, UC Berkeley, Berkeley, CA, September 1987. 

Brief Overview of UC Berkeley’s telescience experiments for the TTPP. 

Koch, David, Terry Herter, John Stauffer, and Erick Young, Telescience Applied to the Space Infrared 
Telescope Facility , 8 pp., Smithosian Astrophysical Observatory (Koch); Department of Astronomy, 
Cornell University (Herter); NASA/Ames Research Center (Stauffer); Steward Observatory, 
University of Arizona (Young), September 1987. 

In the future, the approach to the conduct of scientific space missions will be substantially different 
from the approach that has been used in the past. A more distributed approach will be taken with the 
scientists conducting operations and analysis, remotely from their home institutions, making major use 
of standardized software and compatible hardware. Key to this approach have been the rapid adoption 
of the use of local and wide area networks, the use of standardized software tools and the plethora of 
powerful workstations. These developments will be applied to the Space Infrared Telescope Facility 
project in the space station era. A number of telescience testbed activities are being undertaken to 
develop experience and to determine the applicability of telescience methods, 

Leiner, Barry M., Telescience Testbed Pilot Program , RIACS TR 87.12, 42 pp., RIACS/USRA, Moffett 
Field, CA, May 1987. 

The Telescience Testbed Pilot Program is an innovative activity to address a number of critical issues in 
the conduct of science in the Space Station era. Several scientific experiments using advanced 
information processing and communications technologies will be carried out and the results evaluated 
to determine the requirements and their priorities. This will provide quantitative evidence as to the 
relative importance of different functions in the SSIS and their required performance. Furthermore, it 
will allow a set of scientific users to gain experience with advanced technologies and their application 
to science. This report is based on the proposal from USRA to NASA for the establishment of the 
Telescience Testbed Pilot Program. It describes the motivation for the program, the structure of the 
effort, and several strawman scientific experiments that constitute the heart of the activity. 
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Leiner, Barry M. and James R. Weiss, Telescience Testbedding: An Implementation Approach , RIACS TR 
88.2, 9 pp., RIACS/USRA (Leiner) & NASA/HQS (Weiss), Moffett Field, CA, February 1988. 

Telescience is the term used to describe a concept being developed by NASA’s Office of Space Science 
and Applications (OSSA) under the Science and Applications Information System (SAIS) Program. 
This concept focuses on the development of an ability for all OSSA users to be remotely interactive 
with all provided information system services for the Space Station era. This concept includes access to 
services provided by both flight and ground components of the system and emphasizes the 

accommodation of users from their home institutions. Key to the development of the Telescience 
capability is an implementation approach called rapid-prototype testbedding. This testbedding is used 
to validate the concept and test the applicability of emerging technologies and operational 
methodologies. Testbedding will be used to first determine the feasibility of an idea and the 
applicability to real science usage. Once a concept is deemed viable, it will be integrated into the 
operational system for real time support. It is believed that this approach will gready decrease the 
expense of implementing the eventual system and will enhance the resultant capabilities of the 
delivered systems. 

Leiner, Bany M., Telescience Testbed Pilot Program Interim Report , RIACS TR 88.6, 16 pp., 

RIACS/USRA, Moffett Field, CA, February 1988. 

The Universities Space Research Association (USRA), under sponsorship from the NASA Office of 
Space Science and Applications, is conducting a Telescience Testbed Pilot Program. Fifteen 
universities, under subcontract to USRA, are conducting a variety' of scientific experiments using 
advanced technology to determine the requirements and evaluate trade-offs for the information system 
of the space station era. This report represents an interim set of recommendations based on the 
experiences of the first six months of the pilot program. 

Marchant, Will, Carl A. Dobson, Supriya Chakrabaiti, and Roger F. Malina, “Telescience -Concepts and 
Contributions to the Extreme Ultraviolet Explorer Mission,” SPIE Proceedings , vol. 851, p. 173, 
Astronomy Dept. & Space Sciences Laboratory, UC Berkeley, Berkeley, CA, November 1987. Also 
available in Space Astrophysics Group Contribution Number 315. 

A goal of the telescience concept is to allow scientists to use remotely located instruments as they 
would in their laboratory. Another goal is to increase reliability and scientific return of these 
instruments. In this paper we discuss the role of transparent software tools in development, 
integration, and postlaunch environments to achieve hands on access to the instrument The use of 
transparent tools helps us to reduce the parallel development of capability and to assure that valuable 
pre-launch experience is not lost in the operations phase. We also discuss the use of simulation as a 
rapid prototyping technique. Rapid prototyping provides a cost-effective means of using an iterative 
approach to instrument design. By allowing inexpensive production of testbeds, scientists can quickly 
tune the instrument to produce the desired scientific data. Using portions of the Extreme Ultraviolet 
Explorer (EUVE) system, we examine some of the results of preliminary tests in the use of 
simulation and transparent tools. Additionally, we discuss our efforts to upgrade our software 
"EUVE electronics" simulator to emulate a full instrument, and give the pros and cons of the 
simulation facilities we have developed. 

Pan, Ya-Dung, Teleoperation of Mechanical Manipulators Aboard the US . Space Station, Technical Report 
TSL-002/87, 74 pp.. Electrical and Computer Engineering Department, University of Arizona, Tucson, 
AZ, December 1987. 

This study presents a new analytical controller design strategy for the tele operation of mechanical 
manipulators aboard the U S. space station. This controller design strategy emphasizes on the stability 
of a closed-loop control system involving time delay. Simplified dynamic equations of the Stanford 
arm are considered as the manipulator model. A local linearizing and decoupling control algorithm is 
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applied to linearize and decouple the dynamic equations. Once the linear form of the manipulator is 
obtained, a model prediction control loop is constructed and implemented as a digital controller to 
provide the predictive states information, and a particular model reduction method is applied to yield a 
reduced-order digital controller. This reduced- order digital controller is a highly self-tuned 
controller which can control the closed-loop system with time delay by following a specified 
performance. 

Pennisi, Liz, 44 Computers on Long-Distance Research,” LQP, p. 8, December 7, 1987. 

Magazine article on the use of computers on long-distant research at the University of Arizona. 

Raize, Efraim, Computer Interface for Electrophoresis Apparatus , Technical Report TSL-011/88, 28 pp., 
Electrical and Computer Engineering Department, University of Arizona, Tucson, AZ, May 1988. The 
author is a visiting scholar at the University of Arizona. 

This report summarizes the considerations required for an adequate interface, lists the electronics 
design and shows the drawings and procedures for operation and maintenance of an Electrophoresis 
machine in an automated laboratory. 

Raize, Efraim, Syringe Driver Assembly for Automatic Fluid Handling Laboratory , Technical Report TSL- 
012/88, 17 pp., Electrical and Computer Engineering Department, University of Arizona, Tucson, AZ, 
May 1988. The author is a visiting scholar at the University of Arizona. 

This report describes the design and implementation of a driver assembly for an automated fluid 
handling laboratory, 

Schmerling, Erwin, “The Interaction of Users with Instruments and Databases in Space, ” Information 
Systems Newsletter , pp. 12-18, NASA Headquarters, January 1988. 

This article discusses the Telescience Testbed Pilot Program’s objectives, planned contributions and 
defines the term Telescience. 

Schooley, Larry C. and Francois Cellier, Telescience Testbed Pilot Program Quarterly Report , Technical 
Report TSL-003/87, 16 pp., Electrical and Computer Engineering Department, University of Arizona, 
Tucson, AZ, December 1987. 

First quarterly report for the University of Arizona’s Telescience Testbed Pilot Program. 

Schooley, Larry C., Richard A. Bienz, and Francois Cellier, Basic Research in Telescience Testbed Program 
Final Report: NASA Grant NAGW-1073 , Technical Report TSL-005/88, Electrical and Computer 

Engineering Department, University of Arizona, Tucson, AZ, January 1988. 

Final report for NASA grant NAGW-1073. 

Schooley, Larry C., Don G. Schultz, and Francois Cellier, University of Arizona Presentation, Second 
Telescience Testbed Pilot Program Meeting , Technical Report TSL-007/88, 50 pp., Electrical and 
Computer Engineering, University if Arizona, Tucson, AZ, March 1988. 

The set of transparencies presented by the University of Arizona at the second TTPP meeting held in 
Boulder, CO on March 7-9, 1988. 

Schooley, Larry C. and Francois Cellier, Tele science Testbed Pilot Program Quarterly Report For Winter 
1987-88, Technical Report TSL-008/88, 15 pp., Electrical and Computer Engineering Department, 
University of Arizona, Tucson, AZ, March 1988. 

Second quarterly report for the University of Arizona’s Telescience Testbed Pilot Program. 
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Schooley, Larry C. and Francois Celiier, Telescience Testbed Pilot Program Quarterly Report for Spring 
1988 , Technical Report TSL-0 13/88, 10 pp., Electrical and Computer Engineering Department, 
University of Arizona, Tucson, A Z, June 1988. 

This is the third quarterly report for the astrometric telescope, remote fluid handling, and technology 
development projects at the University of Arizona. It does not include the UA involvement in the 
SIRTF project. 

Starks, Scott, David Elizandro, Barry M. Leiner, and Michael Wiskerchen, “Computer Networks for Remote 
Laboratories in Physics and Engineering,” 1988 Annual Conference of the American Society for 
Engineering Education, June 1988, (also available as RIACS TR 88.13, 7 pp., April 1988). 

As we embark on a new era in engineering education, we must exploit technological advances which 
offer opportunities for improving the educational process. One area of technology which offers 
opportunities for enhancing the manner in which research is conducted and ultimately affects scientific 
and engineering education is computer networks. As computer hardware has become less expensive, 
more numerous and more capable, individuals and organizations have developed a keen interest in 
connecting them together in order to form networks. This in turn has had an impact on the manner in 
which laboratory research is conducted. This paper addresses a relatively new approach to scientific 
research, telescience, which is the conduct of scientific operations in locations remote from the site of 
central experimental activity. A testbed based on the concepts of telescience is being developed to 
ultimately enable scientific researchers on earth to conduct experiments onboard the Space Station. 
This system along with background materials are discussed in this paper. 
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